前言：從新聞事件談起
2025 年台北捷運發生重大事件，媒體曾報導 ASUS 協助檢警「破解」嫌犯筆電。這則新聞讓許多人誤以為廠商擁有「萬用後門」或神秘的破解技術。
真相是：該筆電並未真正啟用 BitLocker 保護，而是處於「Protection Off」狀態，也就是 Clear Key 模式。
ASUS 只是提供同型號電腦，讓系統能夠讀取硬碟上已明文存放的金鑰並正常開機。這並非破解，而是 BitLocker 本身的設計機制。
本文將從技術規格角度，完整解析這個常被誤解的「Clear Key」機制。
文章目錄
Clear Key 機制深度解析
本節將從數位鑑識與資料救援的實務角度，深入分析 BitLocker 的 Clear Key 機制。這是理解「為何某些 BitLocker 加密硬碟不需密碼就能讀取」的關鍵。
現象：為何 UFS Explorer 能直接讀取？
在資料救援實務中，經常遇到以下情況：
- 客戶送來的 BitLocker 加密硬碟，在 PC-3000 等工具中可以直接展開資料，完全不需要輸入密碼或恢復金鑰
- Windows 系統顯示磁碟為「BitLocker 已啟用」，但狀態為 “Waiting for Activation” 或 “Protection Off”
這並非軟硬體「破解」了 AES-256 加密！
實際原因是：硬碟處於以下兩種狀態之一：
- 預先配置（Pre-provisioned）：Windows 安裝時已啟用 BitLocker，但尚未設定保護機制（如 TPM 或密碼）
- 保護暫停（Suspended）：用戶執行過
manage-bde -protectors -disable C:命令
在這兩種狀態下，磁碟上的資料確實已經被 AES 加密，但解密所需的金鑰是以明文形式存放在 FVE Metadata 中。這就是所謂的 Clear Key 模式。
原理：BitLocker 金鑰層級架構
要理解 Clear Key，必須先掌握 BitLocker 的三層金鑰架構：
規格驗證：libbde 文件 Section 5.9 解讀
根據 libbde BitLocker規格文件 Section 5.9（FVE Volume Master Key 結構），以下是 VMK 的完整資料結構：
FVE Volume Master Key (VMK) 結構表
| Offset | 大小 | 欄位名稱 | 說明 |
|---|---|---|---|
| 0 | 16 bytes | Key Identifier | 金鑰識別碼（GUID） |
| 16 | 8 bytes | Last Modification Time | 最後修改時間（FILETIME） |
| 24 | 2 bytes | Unknown | 未知欄位 |
| 26 | 2 bytes | Protection Type | 保護類型（關鍵欄位！） |
| 28 | 變動 | Properties | 巢狀結構，包含解鎖 VMK 所需的材料 |
Key Protection Types（Section 5.9.1）- 最關鍵的表格
Offset 26 的 Protection Type 欄位決定了 VMK 的保護方式：
| 值 | 保護類型 | 說明 |
|---|---|---|
0x0000 |
Clear Key | VMK 以明文金鑰保護（等同未保護） |
0x0100 |
TPM | VMK 由 TPM 晶片保護 |
0x0200 |
Startup Key | VMK 由啟動金鑰（USB）保護 |
0x0500 |
TPM + PIN | VMK 由 TPM 加 PIN 碼保護 |
0x0800 |
Recovery Password | VMK 由 48 位數恢復金鑰保護 |
0x2000 |
Password | VMK 由用戶密碼保護 |
重點：當 Protection Type = 0x0000 時，Offset 28 的 Properties 結構中會包含：
- 256-bit 明文金鑰（Clear Key / KEK）：直接以原始 bytes 存放
- AES-CCM 加密的 VMK：被上述 Clear Key 保護的 Volume Master Key
解密流程
// Step 1: 從 Metadata Offset 28 讀取明文 Clear Key (KEK) clear_key = read_metadata(offset=28, size=32); // 256-bit // Step 2: 用 Clear Key 解密 AES-CCM 封裝的 VMK vmk = aes_ccm_decrypt(encrypted_vmk, key=clear_key); // Step 3: 用 VMK 解密 FVEK fvek = aes_ccm_decrypt(encrypted_fvek, key=vmk); // Step 4: 用 FVEK 解密實際磁碟資料 data = aes_xts_decrypt(sector_data, key=fvek);
這就是為什麼 資料救援設備 等軟體工具能「直接」讀取 Clear Key 模式的 BitLocker 磁碟——它只是按照規格讀取明文存放的 KEK，再一層層解密而已。
觀念釐清：Metadata ≠ FVEK
常見誤區 「FVE Metadata 裡存的就是 FVEK，所以 Clear Key 模式下 FVEK 是明文的」
正確理解
- Metadata 存放的是 VMK 的「解鎖材料」，而非 FVEK
- 即便在 Clear Key 模式，VMK 依然被 AES-CCM 封裝
- 差別只在於：解開 VMK 的鑰匙（KEK）被放在旁邊，就像「把門鎖的鑰匙掛在門把上」
- FVEK 更是被 VMK 多包了一層保護
回到
北捷案：技術真相
現在我們可以理解 ASUS 協助警方的技術細節：
- 嫌犯筆電的 BitLocker 處於 Protection Type = 0x0000（Clear Key 模式）
- 這表示 KEK 以明文形式存放在 FVE Metadata 中
- ASUS 提供同型號電腦，讓系統能正確識別硬體、載入驅動程式
- Windows 開機時自動從 Metadata 讀取 Clear Key → 解密 VMK → 解密 FVEK → 磁碟可讀
這不是「破解」，這是 BitLocker 原本的設計行為。廠商沒有後門，AES 沒有被攻破，只是該筆電從未真正啟用保護機制。
