大家好，小弟最近自己刻了一套會議轉錄系統，最在意的是資安。走的是零信任精神：在不動程式、也拿不到使用者裝置上金鑰的情況下，我無法解密任何人已處理完的會議資料。這邊簡單分享攻擊面怎麼被縮到最小。

裝置端加密，金鑰不落地
音檔在瀏覽器端就先用 XChaCha20-Poly1305（libsodium secretstream，固定 4 MiB 明文分塊）做成密封串流，才透過 SAS 直傳 Azure Blob；Web 主機全程碰不到明文檔，只負責發權限與協調流程。內容加密金鑰（CEK）留在使用者裝置；需要開工時，才在瀏覽器端做成包裹金鑰（wrapped key）——用轉錄主機的非對稱公鑰包起來——並且後端與資料庫都不持久化任何明文金鑰（金鑰只活在當次 Azure Service Bus 訊息裡）。
換句話說：就算有人翻爆資料庫或 Blob 目錄，拿到的仍是密文與中繼資訊；沒有裝置端金鑰／對應的解包能力，連我自己都解不開使用者已封存的會議資料。

轉錄途中怎麼辦？誠實窗口期
音檔要餵給 ASR，一定得在記憶體短暫還原明文，這段我稱為誠實窗口期（Honest Processing Window）——不假裝「處理中也零暴露」，而是把暴露窗口講清楚，並用力縮短。
流程大致是：

Web 把當次任務需要的包裹金鑰（wrapped key）放進 Azure Service Bus 訊息（與 webhook、Blob 路徑等一併傳遞），推給轉錄主機。
轉錄主機用持有的私鑰解包，得到短暫的內容加密金鑰；同時向雲端儲存空間拉取密文音檔。
只在記憶體（RAM）解密、跑 ASR／後處理；跑完立刻銷毀金鑰與明文緩衝，不寫任何明文暫存到硬碟。
進度與結果回報一律走內網 webhook，不繞公網。
轉錄主機不連資料庫，只做轉錄與回傳業務狀態；熱詞等敏感內容以密封形式進入管線，Web 端也只存加密後的資料，不以明文落資料庫。
轉錄主機上的金鑰與解密後的音訊，在誠實窗口期結束後直接在記憶體裡焚化。這是我目前能想到、在「還能實際做 ASR」前提下，明文面曝露最小的作法。威脅模型、區塊大小對齊、金鑰生命週期，都寫在公開白皮書，歡迎直接挑毛病或系統瑕疵，因為我怕我瞎了，工程師的世界很常看不到自己作品裡的蟲：
👉 https://aegismeetings.com/whitepaper