以 Kerberos 保障 J2ME 應用程式安全：第 1 部分 — Kerberos 資料格式深度解析

無線應用程式的普及讓用戶隨時隨地處理敏感資訊成為常態，但也引發了對資料安全的高度關注。業界標準協定 Kerberos 憑藉其強大的雙向驗證、加密傳輸與完整性驗證機制，成為保護行動裝置上財務交易等關鍵業務的不二之選。本系列共三篇文章，將完整示範如何在 J2ME MIDlet 中整合 Kerberos，打造一個能與電子銀行伺服器安全通訊的行動銀行應用程式。

行動銀行應用場景與安全需求

假設有兩位電子銀行用戶 Alice 與 Bob。Alice 想透過 MIDlet 向 Bob 轉帳，輸入對方手機號或帳號後，MIDlet 需安全連線至電子銀行核心系統完成交易，並將確認訊息回傳給 Alice；Bob 同樣可透過 MIDlet 查詢到帳狀態。整個過程中，MIDlet 必須滿足四大安全需求：

• 身分驗證：銀行必須確認發起請求的用戶身分；用戶也必須確認連線的是真實銀行伺服器（雙向驗證）。
• 機密性：所有通訊內容需加密，防止竊聽者解讀敏感資料。
• 完整性：雙方皆可驗證訊息在傳輸過程中未被竄改。
• 可重用性：將 Kerberos 相關邏輯封裝為獨立客戶端元件，方便未來其他 MIDlet 直接引用。

Kerberos 訊息交換流程全景

參與角色包含：支援 J2ME 的行動裝置（內含 MIDlet 與 Kerberos 客戶端）、用戶、電子銀行系統（業務邏輯伺服器與金鑰分發中心 KDC）。KDC 又分為驗證伺服器（AS）與票據授予伺服器（TGS）。整體流程如下（對應圖 1 編號）：

1. 用戶於 MIDlet 輸入帳號密碼（密碼僅用於本地運算，不經網路傳輸）。
2. MIDlet 將帳密交給 Kerberos 客戶端，啟動安全上下文建立流程。
3. 客戶端向 AS 請求票據授予票據（TGT），請求含用戶名但不含密碼。
4. AS 依用戶名查詢內部資料庫取得密碼，以此衍生金鑰加密 TGT 的機密部分，並放入會話金鑰，封裝於回應中返回。
5. 客戶端解密 TGT 取得會話金鑰，隨後向 TGS 請求服務票據，請求內含 TGT 及以會話金鑰加密的鑑別器，並指定目標為電子銀行業務伺服器。
6. TGS 驗證鑑別器、解密 TGT，以業務伺服器金鑰加密服務票據機密部，並置入子會話金鑰，回應並以會話金鑰加密封裝子會話金鑰。
7. 客戶端解密回應取得子會話金鑰與服務票據。
8. 客戶端將服務票據送至業務伺服器，請求建立安全上下文。
9. 業務伺服器解密服務票據取得子會話金鑰，雙方擁有共同金鑰。
10. 業務伺服器回覆確認，雙方即可使用子會話金鑰進行後續安全通訊。

核心訊息結構與 ASN.1 編碼詳解

Kerberos 採用 ASN.1 (Abstract Syntax Notation One) 定義所有資料結構，採 Tag-Length-Value (TLV) 編碼。以下逐一解析關鍵訊息：

1. TGT 請求 (AS-REQ)

結構為 AS-REQ ::= [APPLICATION 10] KDC-REQ，外層 Application Tag 10，內含 KDC-REQ 序列，四大欄位：

• pvno[1] INTEGER：協定版本（固定 5）。
• msg-type[2] INTEGER：訊息類型（10 表 AS-REQ）。
• padata[3] SEQUENCE OF PA-DATA OPTIONAL：預驗證資料，行動裝置為減輕負擔通常略過（需 KDC 設定允許）。
• req-body[4] KDC-REQ-BODY：請求主體，含 kdc-options、cname（用戶名）、realm、sname（TGS 名稱）、till（失效時間）、nonce（隨機數防重放）、etype（支援加密演算法）等。

2. TGT 回應 (AS-REP)

結構 AS-REP ::= [APPLICATION 11] KDC-REP，關鍵欄位：

• ticket[5] Ticket：實際 TGT，含明文部分（版本、realm、sname）與密文部分 enc-part。
• enc-part[6] EncryptedData：以用戶密碼衍生金鑰加密，解密後為 EncKDCRepPart（Application Tag 25），內含會話金鑰、nonce、時間戳、旗標等。

3. 服務票據請求 (TGS-REQ)

結構類似 AS-REQ，但 padata 為必填，封裝 KRB_AP_REQ（Application Tag 14），內含 TGT 及以會話金鑰加密的 Authenticator（含 cksum 校驗 req-body 完整性、時間戳、可選 subkey/seq-number）。

4. 服務票據回應 (TGS-REP)

結構 TGS-REP ::= [APPLICATION 13] KDC-REP，ticket 為服務票據（以業務伺服器金鑰加密），enc-part 以會話金鑰加密，解密後為 EncKDCRepPart（Application Tag 26），內含子會話金鑰。

5. 建立安全上下文請求

客戶端將服務票據封裝於 GSS-API InitialContextToken（Application Tag 0），內含機制 OID (Kerberos V5) 及 KRB_AP_REQ（含服務票據與以子會話金鑰加密的 Authenticator）。

6. 業務伺服器回應

AP-REP（Application Tag 15），enc-part 以子會話金鑰加密，解密後含時間戳、可選 subkey/seq-number，確認上下文建立成功。

7. Kerberos 票據通用結構

Application Tag 1，含版本、realm、sname、enc-part（Application Tag 3 解密後含旗標、金鑰、時間、位址等）。

ASN.1 編碼關鍵細節

• 標籤分類：Application（01）、Context-specific（10）、Universal（00）；第 6 位區分 Primitive (0) / Constructed (1)。
• 長度編碼：短形式（第 8 位 0，長度 ≤127）；長形式（第 8 位 1，後續 7 位表示後續長度位元組數）。
• 通用標籤號：INTEGER=2、BIT STRING=3、OCTET STRING=4、SEQUENCE=16、GeneralizedTime=24、GeneralString=27。

後續展望

下兩篇將實作 J2ME 端 Kerberos 客戶端：

• 第 2 部分：建構 ASN.1 基礎類型、以密碼衍生 DES-CBC 金鑰、產生 TGT 請求。
• 第 3 部分：處理 KDC 回應解析、申請服務票據、建立安全上下文、雙向加密通訊，並整合完整 MIDlet 範例。

本文完整定義了行動銀行安全通訊所需的 Kerberos 訊息格式與交換流程，為後續程式碼實作奠定堅實基礎。