簡介： 用戶需要確保所使用的無線應用程序不會損害他們的敏感信息。其中一種方法就是使用行業標 准協議如 Kerberos 來提供安全性。在本系列中，Faheem Khan 將創建一個示例 J2ME MIDlet，它使用 Kerberos 來保護財務數據。本文是該系列的第一篇文章，他通過解釋為他的應用程序的安全性提供骨架 的 Kerberos 數據格式，介紹了一些基本知識。
許多用戶不願意使用通過無線連接發送敏感數據的應用程序，因為他們不信任無線安全性。但是使傳 統有線網絡上的電子商務的安全成為可能的這些協議，同樣也可以使無線交易成為安全的。在這個由三篇 文章組成的系列中，我將展示 J2ME 客戶機和服務器端 Java 應用程序之間使用 Kerberos 協議進行的安 全消息傳遞。我將開發一個移動銀行 MIDlet 應用程序，它可以通過 Internet 安全地發送和接收付款信 息。MIDlet 應用程序將使用一個基於 J2ME 的 Kerberos 客戶機來進行實際的安全消息傳遞。在本文中 ，我首先解釋移動銀行應用程序的使用模型，然後我將解釋 Kerberos 消息交換的順序，從而為後續的 J2ME 客戶機和服務器端 Java 應用程序之間進行的安全消息傳遞建立安全的上下文。緊接著描述了 Kerberos 消息傳遞中使用的數據格式。本文的最後一部分簡單介紹了 Kerberos 客戶機的體系結構，它 最終創建並處理 Kerberos 消息和數據格式。
一個用於移動銀行的安全 MIDlet
我將首先考慮這樣一個用例場景：其中有兩個擁有電子銀行帳戶的移動電話用戶 Alice 和 Bob。
如果 Alice 想要付款給 Bob，那麼她就向 MIDlet 應用程序提供 Bob 的手機號碼（或者他的銀行帳 戶號碼）並讓 MIDlet 向他付款。MIDlet 安全地與電子銀行聯系並請求電子銀行向 Bob 付款。電子銀行 完成這筆交易並將確認發送回 Alice。Bob 在他的手機上也安裝了 MIDlet，可以用於查看 Alice 的付款 是否到達他的帳戶。MIDlet 安全地與電子銀行進行通信以驗證付款狀態。
我在本系列文章中將設計並實現的 MIDlet 處理所有與電子銀行進行的特定於應用程序的消息傳遞。 當然，MIDlet 必須保證通信是安全的。下面的功能構成了 MIDlet 的安全性需求：
電子銀行應該可以確認請求付款和更新帳戶狀態的用戶的身份。這種安全性需求通常稱為 身份驗證， 其中服務器需要驗證發出請求的客戶的身份。
像 Alice 和 Bob 這樣的用戶應該可以確保他們是真的與電子銀行而不是一些惡意的黑客進行通信。 這也是一種身份驗證的情況，在這裡客戶希望對服務器進行身份驗證。客戶和服務器彼此驗證的情況稱為 雙向身份驗證。
所有通信都應該是加密的以維護消息的機密性。即使黑客可以得到在網絡上傳送的消息字節，他也不 能理解這些加密的數據字節的意義。
通信的雙方（用戶和電子銀行）都應該能夠驗證收到的消息的完整性。如果惡意黑客改變了傳輸中的 消息，那麼接收一方應該可以發現這種改變。
我將使用 Kerberos 協議來滿足這些安全性需求。我將所有與 Kerberos 相關的功能封裝到一個小型 的、適合於 J2ME 設備的客戶端 Kerberos 實現中。我們的移動銀行 MIDlet 只需要負責特定於應用程序 的消息傳遞功能，而 Kerberos 客戶機將處理所有安全問題。
這種技術對於讀者來說有一個好處。Kerberos 客戶機包裝了安全功能（身份驗證、機密性和消息完整 性）。因此，如果要開發自己的 MIDlet，以用於發出和接收付款以外的目的，您也可以使用這裡描述的 Kerberos 客戶機來使之具有安全功能。
本文的大部分用於討論 Kerberos 是如何與應用程序一同工作的，以及描述為了建立安全通信而在客 戶機與服務器之間交換的不同消息。我將在本系列的後續文章中詳細描述客戶端應用程序本身。
Kerberos 消息交換
本節我將描述以下三個參與者之間的 Kerberos 消息交換：
支持 J2ME 的無線設備
無線設備用戶
電子銀行
圖 1. 為建立安全通信上下文而進行的 Kerberos 消息交換
圖 1 給出了三個參與者之間出現的消息交換的概括視圖。本節我將討論這一視圖並解釋圖中顯示的消 息交換的最終結果。下一節解釋每一消息的具體細節（即結構和格式）。
注意，圖 1 中支持 J2ME 的無線設備包含兩個參與者：MIDlet 和 Kerberos 客戶機。與此類似，電 子銀行系統也包含兩個參與者：業務邏輯服務器和 Kerberos 分發中心 (Kerberos Distribution Center ，KDC)。
業務邏輯服務器是實現了電子銀行業務邏輯的服務器端 Java 應用程序。KDC 是一個管理和分發 Kerberos 票據的 Kerberos 服務器。KDC 又由兩個服務器組成：一個 身份驗證服務器(AS) 和一個 票據 授予服務器(TGS)。AS 和 TGS 都接收客戶機請求並發出 Kerberos 票據以響應這些請求。當 AS 接收客 戶機的票據請求時，它發出一個初始票據。然後客戶機向 TGS 展示這個初始票據。TGS 根據這個初始票 據發出服務票據。
獲得初始票據的主要目的是在以後用它得到一個或者多個服務票據。這就是為什麼初始票據也稱為 票 據授予票據(TGT)。
注意，服務票據是用於客戶機與特定服務器之間的安全通信的一種手段。另一方面， TGT 並不是針對 任何特定的服務器的。因此，TGT 邏輯上等於一個開放連接，它的一端是客戶機，而另一端是未知的。當 對一個 TGT 生成一個服務票據時，另一端也就確定了。同一個 TGT 可以用於獲得任意數量的服務票據。
下面描述的消息交換步驟揭開了 MIDlet 如何以及為什麼獲得並使用 Kerberos 票據的神秘面紗。圖 1 中的每一個數字都對應於下面討論的一個步驟。
手機用戶向 MIDlet 應用程序提供他或者她的用戶名和密碼（只由用戶和電子銀行共享的一個秘密） 。這個密碼只用於在 J2ME 應用程序內部的處理，它永遠也不會進入網絡。通過網絡傳輸的只有用戶名。
MIDlet 將用戶名和密碼交給 Kerberos 客戶機。由 Kerberos 客戶機負責建立與電子銀行進行安全通 信的上下文。
Kerberos 客戶機請求 AS 發出一個 TGT。一個 TGT 請求表示一個安全會話。一個客戶機可以在一個 安全會話中建立多個子會話。TGT 請求包含了發出請求的客戶的用戶名，但是不包括密碼（共享的秘密） 。
Kerberos 客戶機向 AS 發送請求。
當 AS 收到 TGT 請求時，它從請求中提出用戶名並從內部數據庫中取出相應的密碼（共享的秘密）。 然後 AS 發布一個 TGT 並將 TGT 包裝在回復消息中。這個 TGT 包含一個純文本部分和一個密碼文本（ 加密的）部分。為了加密 TGT 的密碼部分，AS 使用了由用戶的密碼生成的加密密鑰。因此，只有知道密 碼的用戶才能解開加密的部分。TGT 的加密部分還包含一個加密密鑰，稱為 會話密鑰。
AS 向發出請求的 Kerberos 客戶機發送回復消息（包括 TGT）。
收到 AS 的回復後，Kerberos 客戶機從回復中取出 TGT 並解密 TGT 中加密的部分。然後 Kerberos 客戶機發出一個服務票據請求。這個請求包含了 TGT 和一個稱為 鑒別碼 (authenticator)的加密結構。 客戶機用從 TGT 提取出的會話密鑰加密鑒別碼。鑒別碼證明客戶機掌握會話密鑰。服務票據請求還指定 了電子銀行業務邏輯服務器的名字。
客戶機向 TGS（它是電子銀行的 KDC 的一部分）發送服務票據請求。
收到服務票據請求後，TGS 提取客戶機向其請求服務票據的服務器的名稱，然後授予一個服務票據。 服務票據與 TGT 沒有很大差別。與 TGT 一樣，服務票據包含一個純文本部分和一個密碼文本（加密的） 部分。TGS 用服務器的密鑰（一個用服務器的共享秘密生成的密鑰）加密服務票據的密碼文本部分，這樣 只有那個服務器可以解密這個服務票據的密碼文本部分。TGS 在服務票據的密碼文本部分中還加入了一個 新的加密密鑰。這個密鑰稱為 子會話密鑰。注意現在有兩個密鑰：會話密鑰和子會話密鑰。
授予了服務票據之後，TGS 將服務票據包裝在一個響應消息中。這個響應消息也包含一個密碼文本部 分，它是用會話密鑰加密的。響應消息的密碼文本部分包含子會話密鑰。
TGS 向客戶機發送響應消息。
收到 TGS 響應後，客戶機用會話密鑰解密密碼文本部分，從而提取出子會話密鑰。客戶機還提取服務 票據。
然後客戶機向電子銀行業務邏輯服務器發出消息，並在消息中包裝了服務票據。這個消息請求服務器 與客戶機建立新的安全會話。
客戶機向電子銀行的業務邏輯服務器發送消息。
電子銀行的業務邏輯服務器從請求中提取服務票據，解密它的密碼文本部分，並提取子會話密鑰。這 樣客戶機和服務器就都掌握這個密鑰了。
電子銀行的服務器向客戶機發送一個肯定應答。
客戶機和電子銀行服務器現在可以用子會話密鑰進行安全通信了。
Kerberos 消息
那麼這些加密是如何工作的呢？在本文的其余部分，我將詳細探討圖 1 中步驟 3 到步驟 16 中交換 的 Kerberos 消息的結構。
TGT 請求
圖 2 圖示了在圖 1 的步驟 3 中討論的 TGT 請求消息的表示。
圖2. TGT 請求消息的結構
Kerberos 協議定義了在 Kerberos 消息傳遞中使用的所有數據結構和消息的標題 (title)。注意，圖 2 中消息的標題是 AS-REQ --這是一個 AS 請求。
圖 2 顯示了一種嵌套框的結構。每一個框表示一個數據字段。一些字段又包含了不同的字段，從而構 成了一種嵌套的層次結構。
最外面的框標記為 AS-REQ ，包含一個標記為 KDC-REQ 的更小的框。這個 KDC-REQ 框包含四個字段 ：
pvno ：這個數據字段表示 Kerberos 協議版本號。本系列文章的討論是針對 Kerveros 版本 5 的， 它相當穩定，並且在目前是最新的。
msg-type ：可以通過消息類型號來識別不同的 Kerberos 消息。TGS 請求消息的類型號是 10。
padata ：這是一個可選的字段，在大多數 TGT 請求消息中都沒有它。這個字段的目的是加入身份驗 證信息。在本節後面描述服務票據請求時我將描述 padata 字段的結構。
第四個字段標記為 req-body ，它是 TGT 請求的正文。它又進一步分為幾個字段：
kdc-options ： 這個字段表示 KDC 選項。Kerveros 定義了客戶機可能希望請求的幾個選項。例如， 客戶機可能需要一個 forwardable 票據（可以轉發給不同 KDC 服務器的票據）。與此類似，客戶機可能 會請求一個 renewable 票據（可以在失效後更新的票據）。在本系列文章的後面，我將討論一些可用的 選項，特別是那些與我的移動銀行應用程序有關的選項。
cname ：客戶的用戶名。
realm ：KDC 領域（realm）。注意，使用 Kerberos 的每一個機構都可以建立自己的領域。領域就像 信任域，比如我們的電子銀行。一個領域可能跨越或者不跨越企業邊界。這意味著一個領域可能需要或者 不需要與屬於其他企業的用戶通信。在移動銀行應用程序中，我將盡量保持簡單，假定所有用戶（如 Alice 和 Bob）是在電子銀行自己的企業中注冊的。
sname ：這是一個標識客戶機將向其出示所請求的票據的服務器的名稱。對於 TGT 請求， sname 字 段指定了 TGS 的名稱（因為客戶機最終要向 TGS 展示 TGT）。另一方面，對於服務票據請求（您將在本 節的後面看到它）， sname 字段將指定電子銀行服務器的名稱（因為客戶機最終是要向電子銀行的業務 邏輯服務器出示服務票據）。
from ：這是一個可選的字段，它表明客戶機需要一個填遲日期的票據，即其有效性將在將來的某一時 刻開始。在移動銀行應用程序中我不需要這個功能。
till ：這個字段表明 TGT 失效的時間。客戶機指定 TGT 在什麼時候失效。所有 Kerberos 時間字段 都遵循 YearMonthDateHourMinSecZ 格式。例如，1947 年 8 月 14 日早上 3:30 將表示為 19470814033000Z 。
rtime ：這個字段指定在什麼時刻後票據就不能更新了。這是一個可選的字段，只有當客戶機在 kdc -options 字段中選擇了 renewable 選項後才會使用。
nonce ：這是一個隨機生成的整數。盡管這個整數本身沒有意義，但是它有助於檢測回復攻擊。
etype ：這個字段指定客戶機要使用的加密算法。Kerberos 為常用的加密算法定義了不同的整數，客 戶機將使用對應的整數值。
addresses ：這是一個可選的字段，它包含一組地址，只有從這些地址來的票據才是有效的。客戶可 以在這裡指定從什麼網絡地址上使用所請求的票據。
enc-authorization-data ：這是一個可選字段，它包裝了身份驗證數據，服務器可以根據這些數據來 實施其身份驗證策略。我不准備在移動銀行應用程序中展示這種功能的使用。
additional-tickets ：這是一個可選字段，它使 Kerberos 客戶機可以根據客戶機已經獲得的多個票 據請求一個安全會話。我不准備在移動銀行應用程序中使用這個功能。
用 ASN.1 定義數據結構
Kerberos 用 Abstract Syntax Notation One (ASN.1) 定義在 Kerberos 通信中使用的各種數據結構 和字節格式。ASN.1 是一個 ITU-T (International Telecommunication Union-Telecommunication standardization sector) 標准。它由參考號為 X.680 到 X.699 的不同文檔組成（參閱 參考資料中的 鏈接）。
ASN.1 語法和編碼細節不是本文的重點。不過，我需要對 ASN.1 的概念做一些討論以解釋 Kerberos 結構和字節格式。我將只討論那些解釋 Kerberos 消息格式所需要的 ASN.1 概念。
Kerberos 消息的字節編碼 在討論 Kerberos 消息的其他內容之前，我將首先描述如何將圖 2 中的 TGT 請求消息編碼為字節值序列。
清單 1 是圖 2 中 TGT 請求消息的 ASN.1 類定義(有關 ASN.1 的更多內容見側欄)。稍後的表 2 顯 示了 TGT 請求消息編碼的每一字節的格式。為了理解 TGT 請求消息的字節編碼，必須將圖 2、清單 1 和表 2 聯系在一起。
注意，清單 1 中的主要結構標記為 AS-REQ。相同的 AS-REQ 標記出現在圖 2 中的外圍框中。
現在看一下清單 1 中 AS-REQ 的後面是什麼。AS-REQ 後面的兩個冒號和等號 ( ::= ) 表明這一行定 義了 AS-REQ 結構。接下來是方括號中的一個字符串 APPLICATION 10 。A APPLICATION 10 表明這個 AS-REQ 結構在這個 APPLICATION 的各種結構中是用編號 10 識別的。我們可以說編號 10 是一個 應用 程序級標簽號。這個編號在應用程序中是惟一的―― 換句話說，其他 Kerberos 結構將不會使用這個編 號。
現在注意在 [APPLICATION 10] 字符串後的 KDC-REQ 字符串。這表明在 AS-REQ 結構的格式後面是另 一個名為 KDC-REQ 的結構的定義。這是 ASN.1 中的一種重用機制。KDC-REQ 結構用在兩個地方。因此， Kerberos 定義 KDC-REQ 一次並使用它兩次。
總而言之， AS-REQ ::= [APPLICATION 10] KDC-REQ 表明在該應用程序中的不同結構中 AS-REQ 標記 為 10，後面是另一個名為 KDC-REQ 的結構的定義。
清單 1. TGT 請求消息的 ASN.1 類定義
AS-REQ ::= [APPLICATION 10] KDC-REQ
KDC-REQ ::= SEQUENCE {
pvno[1] INTEGER,
msg-type[2] INTEGER,
padata[3] SEQUENCE OF PA-DATA OPTIONAL,
req-body[4] KDC-REQ-BODY
}
PA-DATA ::= SEQUENCE {
padata-type[1] INTEGER,
padata-value[2] OCTET STRING,
-- might be encoded AP-REQ
}
KDC-REQ-BODY ::= SEQUENCE {
kdc-options[0] KDCOptions,
cname[1] PrincipalName OPTIONAL,
-- Used only in AS-REQ
realm[2] Realm, -- Server's realm
-- Also client's in AS-REQ
sname[3] PrincipalName OPTIONAL,
from[4] KerberosTime OPTIONAL,
till[5] KerberosTime,
rtime[6] KerberosTime OPTIONAL,
nonce[7] INTEGER,
etype[8] SEQUENCE OF INTEGER, -- EncryptionType,
-- in preference order
addresses[9] HostAddresses OPTIONAL,
enc-authorization-data[10] EncryptedData OPTIONAL,
-- Encrypted AuthorizationData encoding
additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
}
EncryptedData ::= SEQUENCE {
etype[0] INTEGER, -- EncryptionType
kvno[1] INTEGER OPTIONAL,
cipher[2] OCTET STRING -- ciphertext
}
KDCOptions ::= BIT STRING {
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
allow-postdate(5),
postdated(6),
unused7(7),
renewable(8),
unused9(9),
unused10(10),
unused11(11),
renewable-ok(27),
enc-tkt-in-skey(28),
renew(30),
validate(31)
}
PrincipalName ::= SEQUENCE {
name-type[0] INTEGER,
name-string[1] SEQUENCE OF GeneralString
}
KerberosTime ::= GeneralizedTime
-- Specifying UTC time zone (Z)
HostAddresses ::= SEQUENCE OF SEQUENCE {
addr-type[0] INTEGER,
address[1] OCTET STRING
}
現在讓我們來看一下 KDC-REQ 結構。
清單 1 中的 KDC-REQ ::= SEQUENCE 這一行表明 KDC-REQ 結構是不同數據結構的序列。在 SEQUENCE 關鍵詞後的一組花括號描述了共同構成 KDC-REQ 結構的數據結構。
花括號中有四行代碼。第一行 ( pvno[1] INTEGER ) 定義了 KDC-REQ 結構的第一個元素，它是圖 2 中的 pvno 字段。
第二行 ( msg-type[2] INTEGER ) 對應於圖 2 中的 msg-type 字段。注意 pvno 和 msg-type 字段 的類型為 INTEGER ，這意味著它們是用 INTEGER 數據類型構建的。
還要注意在清單 1 中 pvno 和 msg-type 後面的方括號中的數字 ( pvno[1] and msg-type[2] )。與 在前面 AS-REQ ::= [APPLICATION 10] KDC-REQ 一行中見到的應用程序級標簽號相反，它們是 上下文特 定的標簽號。
應用程序級和上下文特定的標簽號有什麼區別呢？應用程序級標簽號在整個應用程序中是惟一的和有 效的。例如，在整個 Kerberos 應用程序中編號 10 都是指 AS-REQ 結構。而上下文特定的標簽號只在定 義它們的上下文中有意義。例如，在 KDC-REQ 的結構內部，上下文特定的標簽號 1 表示 pvno 。但是在 查看其他結構的內部時，同樣的上下文特定的標簽號 1 表示的則是一些其他的字段。
在後面討論將清單 1 編碼為表 2 中的字節序列時，我將解釋這些應用程序級和上下文特定的標簽號 的使用。
現在看一看清單 1 中 KDC-REQ 結構中第三行 ( padata[3] SEQUENCE OF PA-DATA ) 和第四行 ( req-body[4] KDC-REQ-BODY )。第三行定義了圖 2 中的 padata 字段，它是 PA-DATA 結構的一個 SEQUENCE 。第四行表示圖 2 中的 req-body 框。
padata 和 req-body 字段又是由不同字段組成的 Kerberos 結構。例如， req-body 的數據類型是 KDC-REQ-BODY ，而該數據類型自己又是一個帶有幾個字段（像前面討論的那樣帶有 kdc-options、 cname 、 realm 、 sname 、 till 、 nonce 和 etype 等字段）的 Kerberos 結構。
回想一下 pvno 字段是用一個 INTEGER 構建的。另一方面， req-body 字段的數據類型為 KDC-REQ- BODY ，該數據類型本身又是由幾個字段構建的一種結構。
還要注意 INTEGER 是基本 ASN.1 數據類型的一個例子，而 KDC-REQ-BODY 是由其他字段構建的派生 數據類型。
ASN.1 定義了一些可以被應用程序使用的數據類型，稱為 通用數據類型。大多數通用數據類型是基本 類型，只有少數是構建的。ASN.1 為通用數據類型定義了 標簽號，如表 1 所示。
表 1. 一些通用數據類型和標簽號
通用數據類型 通用標簽號 構建類型還是基本類型? BOOLEAN 1 基本類型 INTEGER 2 基本類型 BIT STRING 3 基本類型 OCTET STRING 4 基本類型 SEQUENCE 16 構建類型 GeneralizedTime 24 基本類型 GeneralString 27 基本類型
表 1 顯示 INTEGER 數據類型的通用標簽號是 2，並且 INTEGER 數據類型是基本類型。SEQUENCE 是 表 1 中惟一的構建類型的通用標簽。這是因為 SEQUENCE 數據類型是使用其他字段普遍定義的， SEQUENCE 總是用其他字段構建的。
在 ASN.1 定義中沒有提到通用數據類型的標簽號，這是因為這些標簽號已經得到普遍定義和理解。不 過，在試圖將 Kerberos 結構編碼為字節序列時需要用到通用標簽號。在稍後您會看到這一點。
現在，讓我解釋圖 2 與清單 1 中的 AS-REQ 消息是如何編碼為字節序列的。為了展示這個編碼過程 ，我提供了表 2，它顯示了客戶機發送給 KDC 服務器以請求 TGT 的 TGT 請求（一個 AS-REQ 結構）中 實際的字節序列。表 2 中顯示的字節序列是我們要分析的 AS-REQ 編碼過程的最終結果。
因為它比較長，所以我用一個 單獨的文件來提供表 2。在閱讀進行下面的討論時您應該在一個單獨的 浏覽器窗口中打開它。
看一下表 2 中的第一個字節 ( 01101010 )。這是消息的第一個字節，表示清單 1 的 AS-REQ 結構的 開始（圖 2 中的外圍框）。位 8 和位 7 ( 01 ) 表明這是一個應用程序級標簽。位 6 ( 1 ) 表明這是 一個構建的結構。位 5 到位 1 ( 01010 ) 表示 AS-REQ 的標簽號（我在前面的討論中說過 AS-REQ 結構 的應用級標簽號為 10，其二進制表示為 01010 ）。
可以將標簽字節分為三部分：
位 8 和位 7 指定標簽的 類型或者類。對於應用程序級標簽，位 8 和位 7 應該是 01 ，對於上下文 特定的標簽，它們應該是 10 ，對於通用標簽，它們是 00 。
位 6 指定標簽是基本的 ( 0 ) 還是構建的 ( 1 )。
位 5 到位 1 編碼標簽號。
因為用於表示標簽號的位數限制了可以您可以擁有的標簽的個數，所以您可能奇怪為什麼只有 5 位用 於標簽號。ASN.1 定義了編碼標簽號的一個完整機制，與標簽號的大小無關。不過，Kerberos 沒有定義 任何不能用 5 位表達的標簽號。因此，為了將討論集中於 Kerberos，我在這裡將不討論如何處理大的標 簽號。
現在，看一下表 2 中的第二個字節 ( 10000001 )。在標簽字節後，有一個或者多個 長度字節。這些 長度字節指定了構成完整標簽的總字節數。
有兩種定義長度字節的方法。第一種是 單字節長度表示，第二種是 多字節長度表示。對於單字節長 度表示，要使第一個長度字節的位 8 為 0 ，並用其余的位指定長度字節的個數。例如，如果您想說這個 結構中有 65 個字節，可以將長度值編碼為 01000001 （位 8 設置為 0 ，位 7 到位 1――1000001 ― ―表示 65）。在這種方法中，總是有一個長度字節，下一個字節標記結構內容的開始。用這種方法可編 碼的最大值是 127。
對於多字節表示法，設置第一個長度字節的位 8 為 1 ，並用位 7 到位 1 指定隨後的長度字節的個 數。例如，如果要編碼值 210，第一個長度字節將是 10000001 （位 8 設置為 1 ，位 7 到位 1 設置為 1 ，即 0000001 表明還有一個長度字節)，後面再跟一個字節，其值為 11010010 （表示十進制的 210 ）。
看一下表 2 中的字節 2 和字節 3 ，它們分別是 10000001 和 11010010 。這意味著我用多字節長度 表示法來指定 AS-REQ 結構的長度，即 210 。
注意在表 2 中共有 213 字節，其中 210 是在第 3 個字節後。在字節 3 後的所有 210 個字節都屬 於 AS-REQ 結構。因此，第 4 個字節和後面的所有字節構成了 AS-REQ 結構的內容。
注意，清單 1 中 AS-REQ 結構後面是 KDC-REQ 結構的定義，這個結構是一個 SEQUENCE 。回想一下 ，在表 1 中 SEQUENCE 是 通用標簽，它是 構建的數據類型，並且其標簽號為 16。這就是為什麼表 2 中字節 4 的值為 00110000 。位 8 和位 7 ( 00 ) 指定這是一個通用標簽。位 6 ( 1 ) 表明這個結構 是構建的。位 5 到位 1 指定標簽號，對於 SEQUENCE 來說這是 16（二進制為 10000 ）。
字節 5 和字節 6 指定 KDC-REQ 結構中的字節數。字節 5 ( 10000001 ) 指定有一個長度字節。字節 6 ( 11001111 ) 指定 KDC-REQ 序列的實際長度 (207)。我已經解釋過長度字節的工作方式。
清單 1 中 KDC-REQ 序列的第一個字段是 pvno ，它是一個 上下文特定的，構建 的字段，其標簽號 為 1 。表 2 中的字節 7 ( 10100001 ) 表示這個字段。位 8 和位 7 ( 10 ) 表示這是一個上下文特定 的標簽。位 6 ( 1 ) 表示這是一個構建的字段，位 5 到位 1 ( 00001 ) 指定 pvno 字段的標簽號。
字節 8 ( 00000011 ) 指定 pvno 字段的長度。這個長度字節的位 8 是 0 ，這表明我使用單字節長 度表示法。位 7 到位 1 ( 0000011 ) 指定長度為 3。這裡要注意，正如前面所解釋的，當結構的長度小 於 127 時，我就使用單字節長度表示法。
pvno 字段的內容從表 2 中的第 9 個字節開始。pvno 字段是用 INTEGER 基本數據類型構建的，所以 我可以期望 pvno 的內容為一個整數值。
字節 9 ( 00000010 ) 表示 INTEGER 標簽。位 8 和位 7 ( 00 ) 標識這是一個通用標簽，位 6 (0) 說明它是基本類型，位 5 到位 1 ( 00010 ) 表明標簽號為 2（見表 1）。
位 10 ( 00000001 ) 提供了這個 INTEGER 數據類型在單字節長度表示法中的長度。INTEGER 值只由 一個字節組成，即下一個字節（第 11 個字節）。
您將注意到字節編碼過程遵循一個清晰的模式。我以對應於清單 1 中一個字段的標簽值開始。標簽值 後面是長度字節，長度字節後面是標簽的內容。我不斷使用嵌套的、分層次的構建結構，直到達到一個基 本數據類型。
您可以根據這種模式完成表 2。表 2 的說明欄可以幫助您理解每一字節的作用。對於本文中的要討論 的其他消息，我不會提供逐字節的分析，不過對這個消息的分析可以使您了解它們的工作方式。
包裝 TGT 的響應
圖 3 是一個 AS 發出的、包裝了 TGT 的響應消息的圖形表示。圖 3 同樣使用了圖 2 中展示的嵌套 框結構。
圖 3. AS 的 TGT 響應的結構
圖 3 中的主框（外圍框）標記為 AS-REP ，它包含一個標記為 KDC-REP 的更小的框。KDC-REP 是由 幾個字段組成的一個序列。
pvno ：在討論圖 2 時我解釋了這個字段。
msg-type ：消息的類型。它是一個整數，對於 TGT 響應消息它的值應該為 11。
padata ：在討論圖 2 時我對這個字段做過說明。這是一個可選字段，在大多數 TGT 響應消息中沒使 用它。
crealm 和 cname ：在討論圖 2 時對這些字段做過說明。
ticket ：實際的 TGT。我將在本文的後面一節中討論 Kerberos 票據自身的格式。
enc-part ：這是一個加密數據的包裝器。Kerveros 消息中所有加密的部分都包含三個字段：
etype ：指定用於進行密碼加密的加密算法的標識符。
kvno ：用於加密的加密密鑰的版本。AS 使用客戶機的密鑰進行加密。這個字段指定用於進行加密的 密鑰的版本。
cipher ：一系列字節。這是實際的加密數據。數據解密後，我就有了另一個結構，如圖 4 所示。
圖 4. TGT 響應消息的加密部分的結構
圖 4 顯示了對 TGT 響應消息中加密部分進行解密後得到的結構。它包含以下字段：
key ：這是會話密鑰。當前會話的後續通信將使用這個密鑰而不是密碼密鑰。
last-req ：這個字段指定客戶機的最後一次票據請求的時間。這個字段有助於通知客戶機，它的請求 已經收到了。
nonce ：在討論圖 2 時我對這個字段做過說明。AS 將包含它在請求中收到的隨機數的一個副本。這 有助於檢測回復攻擊。如果黑客取得了 TGT 響應並想反復回復它，那麼客戶機就可以將響應的 nonce 字 段與其請求進行比較以檢測回復。
key-expiration ：這是一個可選字段，它指定客戶機的密鑰失效的時間。
flags ：這個字段對應於圖 2 的 TGT 請求的 kdc-options 字段。這些 flags 表示 Kerberos 客戶 機可能請求的不同可選功能。AS 將標志發送回客戶機，從而允許客戶機比較 AS 是否可以提供所請求的 可選功能。
authtime ：AS 發出票據的時間。
starttime ：票據生效的時間。
endtime ：票據失效的時間。
renew-till ：可更新的票據的最終失效時間。
srealm ：服務器的領域。
sname ：服務器名，其所帶票據是有效的。
caddr ：這個字段指定一個地址列表，這些地址給出的相應票據是可以使用的。這個字段的目的是使 黑客使用偷來的票據更困難。
清單 2 提供了 TGT 響應消息的 ASN.1 類定義。讀者可以將清單 2 中的類定義與圖 3 和圖 4 中顯 示的不同字段相對照。
清單 2. TGT 響應消息的 ASN.1 類定義
AS-REP ::= [APPLICATION 11] KDC-REP
KDC-REP ::= SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
padata[2] SEQUENCE OF PA-DATA OPTIONAL,
crealm[3] Realm,
cname[4] PrincipalName,
ticket[5] Ticket,
enc-part[6] EncryptedData
}
EncryptedData ::= SEQUENCE {
etype[0] INTEGER, -- EncryptionType
kvno[1] INTEGER OPTIONAL,
cipher[2] OCTET STRING -- ciphertext
}
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
key[0] EncryptionKey,
last-req[1] LastReq,
nonce[2] INTEGER,
key-expiration[3] KerberosTime OPTIONAL,
flags[4] TicketFlags,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
srealm[9] Realm,
sname[10] PrincipalName,
caddr[11] HostAddresses OPTIONAL
}
服務票據請求
收到 TGT 後，客戶機發出服務票據請求，如圖 5 所示。服務票據請求與我在圖 2 中討論的 TGT 請 求非常相似。可以將圖 5 中的所有字段與圖 2 中的相應字段進行對照。我只需要解釋專門針對服務票據 請求的 padata 字段。
圖 5. 服務票據請求消息的結構
padata 字段是 PA-DATA 結構的序列，它包含 身份驗證數據。服務票據請求需要向票據授予服務器發 送 TGT。padata 字段將 TGT 包裝到它的一個 PA-DATA 結構中。
Kerberos 用 padata 字段實現不同的目的,包裝 TGT 只是其中一項。因此，Kerberos 定義了不同的 整數值以指定 PA-DATA 結構包裝的是什麼類型的數據。
圖 5 顯示 PA-DATA 序列只包含一個 PA-DATA 結構，它由兩個子字段組成，即 padata-type 和 padata-value 。padata 序列中的每一個 PA-DATA 結構都包含這兩個字段。
padata-type 是一個整數值，用於指定所帶 padata-value 字段中的數據類型。當在服務票據請求中 padata-value 字段包裝了一個 TGT 時， padata-type 字段的值就是 1。
padata-value 字段是一串字節，其中包含 TGT。padata-value 字段中的字節串實際上是另一個名為 KRB_AP_REQ （或者簡稱為 AP-REQ ）的 Kerberos 結構，也稱為 身份驗證頭。
身份驗證頭包含 TGT 以及一些其他字段，如下所示：
pvno ：在對圖 2 的討論中我已經解釋過這個字段。
message-type ：這個字段包含一個整數值 (12)，用於識別 KRB_TGS_REQ 消息。
ap-options ：這是一組選項。第一個選項保留為以後使用。第二個選項指定相應 TGT 是用包裝在相 應 TGT 中的會話密鑰加密的。因為 TGS 已經知道會話密鑰，所以它可以使用這把密鑰進行解密。如果選 擇了第三個選項，那麼它就指定客戶機請求雙向身份驗證。
ticket ：TGT 本身。
authenticator ：這是一個加密的結構，其中包含幾個字段，允許客戶機證明它擁有會話密鑰並幫助 TGS 檢測回復攻擊。在身份驗證頭中 鑒別碼是以加密的（密文）形式出現的。客戶機使用會話密鑰加密 鑒別碼。鑒別碼結構的字段如下：
authenticator-vno ：鑒別碼格式的版本號。對於 Kerberos 版本 5，這個字段應該指定 5。
crealm 和 cname： 我在對圖 2 的討論中解釋了這些字段。
cksum ：一個校驗和或者散列值，由圖 5 中顯示的 req-body 字段的字節編碼計算而來。這個字段讓 TGS 可以檢查請求消息的完整性。因為該校驗和位於一個用會話密鑰加密的結構中，所以這個字段也證明 客戶機擁有會話密鑰。
cusec 和 ctime ：這兩個字段共同指定發出 KRB_AP_REQ 消息的客戶機時間。cusec 字段指定時間的 微秒部分，而 ctime 字段指定日期和以毫秒計的時間。
subkey ：這是一個可選的字段，客戶機可以用它指定隨後與服務器之間的通信所要使用的密鑰。對於 移動銀行應用程序，我將盡量減少在 J2ME 客戶機上的處理負荷，因此，讓服務器決定會話密鑰和子會話 密鑰。
seq-number ：這是一個可選字段，可以包含消息的一個序列號以檢測回復攻擊。
authorization-data ：這是一個可選字段，帶有特定於應用程序的身份驗證數據。在移動銀行應用程 序中我沒有使用這個字段。
清單 3 提供了服務票據請求消息的 ASN.1 類定義。讀者可以將圖 5 中顯示的不同字段與清單 3 中 的類定義相對照。
清單 3. 服務票據請求消息的 ASN.1 類定義
TGS-REQ ::= [APPLICATION 12] KDC-REQ
KDC-REQ ::= SEQUENCE {
pvno[1] INTEGER,
msg-type[2] INTEGER,
padata[3] SEQUENCE OF PA-DATA OPTIONAL,
req-body[4] KDC-REQ-BODY
}
PA-DATA ::= SEQUENCE {
padata-type[1] INTEGER,
padata-value[2] OCTET STRING,
-- might be encoded AP-REQ
}
KDC-REQ-BODY ::= SEQUENCE {
kdc-options[0] KDCOptions,
realm[2] Realm, -- Server's realm
-- Also client's in AS-REQ
sname[3] PrincipalName OPTIONAL,
from[4] KerberosTime OPTIONAL,
till[5] KerberosTime,
rtime[6] KerberosTime OPTIONAL,
nonce[7] INTEGER,
etype[8] SEQUENCE OF INTEGER, -- EncryptionType,
-- in preference order
addresses[9] HostAddresses OPTIONAL,
enc-authorization-data[10] EncryptedData OPTIONAL,
-- Encrypted AuthorizationData encoding
additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
}
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER, -- indicates Version 5
msg-type [1] INTEGER, -- indicates KRB_AP_REQ
ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}
APOptions ::= BIT STRING {
reserved (0),
use-session-key (1),
mutual-required (2)
}
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER, -- indicates Version 5
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] INTEGER,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER OPTIONAL,
authorization-data[8] AuthorizationData OPTIONAL
}
響應包含服務票據
當 TGS 收到服務票據的請求時，它就在響應中發出一個服務票據。圖 6 顯示了包裝有服務票據的 TGS 響應。您可以對照圖 6 與圖 3。您會發現圖 3 中顯示的字段與在圖 6 中顯示的一樣，只不過圖 3 中的 ticket 字段是 TGT，而圖 6 的 ticket 字段是服務票據。
還要注意，在產生圖 6 的加密部分時，KDC 使用了在以前的消息中與客戶機交換的會話密鑰。服務票 據包裝了客戶機與電子銀行服務器進行安全通信時將會使用的子會話密鑰。
圖 6. TGS 的服務票據響應的結構
清單 4 提供了服務票據響應消息的 ASN.1 類定義。讀者可以將圖 6 中不同字段與清單 4 中的類定 義進行對照。
清單 4. 服務票據響應消息的 ASN.1 類定義
TGS-REP ::= [APPLICATION 13] KDC-REP
KDC-REP ::= SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
padata[2] SEQUENCE OF PA-DATA OPTIONAL,
crealm[3] Realm,
cname[4] PrincipalName,
ticket[5] Ticket,
enc-part[6] EncryptedData
}
EncryptedData ::= SEQUENCE {
etype[0] INTEGER, -- EncryptionType
kvno[1] INTEGER OPTIONAL,
cipher[2] OCTET STRING -- ciphertext
}
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
key[0] EncryptionKey,
last-req[1] LastReq,
nonce[2] INTEGER,
key-expiration[3] KerberosTime OPTIONAL,
flags[4] TicketFlags,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
srealm[9] Realm,
sname[10] PrincipalName,
caddr[11] HostAddresses OPTIONAL
}
從客戶機到電子銀行業務邏輯服務器的消息
現在客戶機有了服務票據，可以將它發送到電子銀行業務邏輯服務器。客戶機發送圖 7 中的消息到電 子銀行服務器。這個消息的目的是請求服務器建立與客戶機的新的安全上下文。
圖 7. 從 Kerberos 客戶機到電子銀行服務器的消息的結構
我說過本文的目的是展示基於 J2ME 的安全移動銀行應用程序。我准備在服務器端使用 Generic Security Services API（GSS API，或者簡稱為 GSS）來為電子銀行業務邏輯服務器提供安全功能。GSS 是一種一般性的高層安全 API ，它可以在像 Kerberos 這樣的不同安全技術上面工作。
我將在本系列的第三篇文章中討論 GSS API 在電子銀行業務邏輯服務器中的使用。現在，只要知道與 Kerberos 一樣，GSS 也是一種 IETF 標准。IETF 為客戶機與服務器之間相互傳遞的 Kerveros 消息定義 了 GSS 包裝器。為了在服務器端使用 GSS，我必須保證 GSS 客戶機可以發出並處理 GSS 包裝器。
圖 7 中的外圍框標記為 InitialContextToken ，它實際上是包裝了從 GSS 客戶機到 GSS 服務器的 消息的 GSS 包裝器的名字。在 InitialContextToken 包裝器中，第一個字段名為 thisMech ，它定義了 GSS 作為低層安全技術使用的安全機制（在這裡是 Kerveros）。
InitialContextToken 框中的第二個字段標記為 KRB_AP_REQ ，我在討論圖 5 時分析過它。回想一下 前面的討論中說過 KRB_AP_REQ 結構包裝了票據。這就是為什麼我可以使用這個結構包裝一個服務票據並 發送給電子銀行服務器。我說過服務票據已經包含了子會話密鑰。
清單 5 提供了 Kerberos 客戶機發給電子銀行業務邏輯服務器的消息的 ASN.1 類定義。您可以將圖 7 中的不同字段與清單 5 中的類定義進行對照。
清單 5. 從客戶機到服務器的安全上下文請求消息的 ASN.1 類定義
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType
-- MechType is OBJECT IDENTIFIER
-- representing "Kerberos V5"
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific;
-- ASN.1 usage within innerContextToken
-- is not required
}
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER, -- indicates Version 5
msg-type [1] INTEGER, -- indicates KRB_AP_REQ
ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}
APOptions ::= BIT STRING {
reserved (0),
use-session-key (1),
mutual-required (2)
}
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER, -- indicates Version 5
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] INTEGER,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER OPTIONAL,
authorization-data[8] AuthorizationData OPTIONAL
}
電子銀行的響應
當電子銀行的業務邏輯服務器收到圖 7 中的消息時，它提取出服務票據並解密票據中的加密部分以得 到子會話密鑰。客戶機已經有了同樣的子會話密鑰。因此，服務器和客戶機可以使用這個子會話密鑰彼此 進行安全通信。
圖 8. 電子銀行對 Kerberos 客戶機的響應的結構
電子銀行業務邏輯服務器向客戶機發回一個確認消息，如圖 8 所示。下面是構成圖 8 的消息的字段 ：
pvno ：我在對圖 2 的討論中解釋了這個字段。
msg-type ：這是具有整數值 14 的消息類型標識符。
enc-part ：消息的加密部分。客戶機將用子會話密鑰解密這個加密部分。在解密時，它將展現另一個 帶有以下字段的結構：
ctime 和 cusec ：我在對圖 6 的討論中解釋了這些字段。
subkey ：這是一個服務器可能發送給客戶機的可選密鑰。如果服務器將這個密鑰發送給客戶機，那麼 這個密鑰將被用於隨後客戶機與服務器之間的安全通信（取代子會話密鑰）。
seq-number ：我在對圖 5 的討論中解釋了這個字段。
清單 6 提供了電子銀行對 Kerveros 客戶機的響應的 ASN.1 類定義。讀者可以將圖 8 中顯示的不同 字段與清單 6 中的類定義相對照。
清單 6. 從服務器到客戶機的安全上下文響應的 ASN.1 類定義
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER, -- represents Kerberos V5
msg-type [1] INTEGER, -- represents KRB_AP_REP
enc-part [2] EncryptedData
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] INTEGER,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] INTEGER OPTIONAL
}
Kerberos 票據
在結束這篇文章之前，我想要展示 Kerberos 票據本身的結構。圖 9 顯示了 Kerberos 票據的結構。
圖 9. Kerberos 票據的結構
它包含 11 個字段：
tkt-vno ：票據格式的版本。當前它是 5。
realm 和 sname ：我在對圖 2 的討論中解釋了這些字段。這兩個字段共同指定可以給出有效票據的 服務器的完整標識符。對於 TGT，這兩個字段標識了 TGS。另一方面，對於服務票據，它們指定電子銀行 業務邏輯服務器。
enc-part ：這是票據的機密部分。這個加密的部分解密後是另一個 Kerberos 結構，它包含如下所描 述的一些字段：
flags ：這是我在討論圖 2 中的 kdc-options 字段時提到的一組標志。其中一個標志用於說明這是 TGT 還是服務票據。
key ：這是會話密鑰（對於 TGT）或者子會話密鑰（對於服務票據）。
creal 和 cname ：我在對圖 2 的討論中解釋了這些字段。
transited ：正如前面提到的，在不同領域中工作的不同 Kerberos 服務器可以將票據從一個領域轉 發到另一個領域。這個字段指定在發布這種票據時所涉及的不同領域的名字。在移動銀行應用程序中我不 需要這種功能。
authtime ：這是 KDC 驗證請求客戶身份的時間。
starttime 和 endtime ：票據從 starttime 到 endtime 是有效的。
renew-till ：正如前面提到的，Kerberos 票據是可以更新的。這種票據可以包含這個字段，它指定 票據的最終失效時間。在這個時間之後，票據將不再是 renewable 的。
caddr ：我在對圖 4 的討論中解釋了這個字段。
展望：設計 Kerberos 客戶機
在本系列的其余部分，我將構建一個 Kerberos 客戶機，它為移動銀行應用程序提供安全功能。 Kerberos 客戶機的主要目的是發布並處理這裡詳細說明的 Kerberos 消息。客戶機將可以從客戶機向票 據或者電子銀行服務器發布所有消息（圖 2、5 和 7 所示的消息）並處理從服務器發回的消息（圖 2、4 、6、8 和 9 所示的消息）。
我所開發的 Kerberos 客戶機將在資源有限的無線設備上運行。因此，客戶機只有很少的資源。我的 重點放在高效地使用可用的設備資源上。
安全應用程序通常使設備資源承擔繁重的處理負荷。為了提高程序的效率，我必須對良好的面向對象 的設計做法做出一些妥協。這對於 重大的 J2ME 應用程序來說是很常見的。本系列的後兩篇文章中將展 示在移動銀行應用程序中是如何做的。
結束語
在本文中，我解釋了移動銀行應用程序的使用模型和安全性需求。我還描述了在 Kerberos 客戶機和 一個電子銀行服務器之間交換加密密鑰以進行安全通信的 Kerberos 消息的序列（以及 Kerberos 數據格 式）。然後我簡要展望了要在本系列後兩篇文章中構建的 J2ME Kerberos 客戶機。
我希望本文的內容對於所有希望了解 Kerberos 消息的工作細節的讀者可以提供有用的信息。在寫作 本系列的其余部分時我需要用到所有這些信息。
