加密軟體核心原理：加密後檔案載入與解密順序

一般檔案加密軟體核心流程分為 靜態加密 (檔案落地加密) 與 動態解密 (記憶體中透明解密) 兩階段：

典型架構

1. 加密階段 (離線/部署時)：
   • 讀取原始檔案 (如 image.png)。
   • 生成隨機金鑰 (或派生自主金鑰)，用 AES-256-GCM 等演算法加密內容。
   • 將金鑰用 RSA 公鑰加密 (或存入授權伺服器)，附加在檔案頭或獨立 .key 檔。
   • 輸出 image.enc，原始檔案銷毀。
2. 解密/使用階段 (運行時)：
   • 應用啟動時載入驅動/鉤子 (Windows: Minifilter/文件系統過濾器；Linux: FUSE/OverlayFS；Android: VFS/ClassLoader 鉤子)。
   • 進程讀取 image.enc 時，驅動攔截 ReadFile/open，透明解密後將明文資料傳給應用。
   • 應用層 完全感知不到加密，直接用標準 API (ImageIO.read, BitmapFactory.decodeStream) 載入，拿到的是解密後的位元組流。

你的問題：先 Load 再解密，還是先解密再 Load？

答案：應用層直接 Load 加密檔，底層驅動透明解密，應用拿到的是明文。 即「Load 時解密」，而非「解密出臨時檔再 Load」(那樣會留下明文殘留、效能差、安全性低)。

關鍵技術點

• 隨機讀取支援：驅動必須支援 seek，只解密被讀取的區塊 (如 AES-CTR 模式支援並行隨機讀取)。
• 金鑰管理：主金鑰不落地，存於 TPM/TEE/安全區，授權時派生檔案金鑰。
• 完整性驗證：GCM 模式自帶認證標籤，防止密文竄改。
• 白名單進程：僅授權進程 (你的 App) 能讀取明文，其他進程 (備份工具、惡意軟體) 讀到的是密文。

若你有原始碼，建議搜尋 IRP_MJ_READ (Windows)、fuse_read (Linux)、ClassLoader.defineClass (Java/Android) 等關鍵攔截點，理解透明解密實現細節。