Let's Encrypt 公布後量子演算法移轉路線：Merkle Tree Certificates + ML-DSA，2026 年底進入 Staging
Let's Encrypt · 2026-06-03
Let's Encrypt 於 2026 年 6 月 3 日發布了面向後量子密碼學的詳細移轉計畫，以 Merkle Tree Certificates（MTC） 搭配 NIST 標準化後量子簽名演算法 ML-DSA 為核心路線，計畫在 2026 年底建立 staging 環境，2027 年進入生產。
為什麼是 MTC 而非直接替換簽名演算法
傳統的 X.509 憑證以單一私鑰對每張憑證獨立簽名。後量子簽名演算法（如 ML-DSA）的簽名大小遠大於現有演算法：
| 演算法 | 簽名大小 | 公鑰大小 |
|---|---|---|
| ECDSA P-256 | 64 bytes | 64 bytes |
| RSA-2048 | 256 bytes | 256 bytes |
| ML-DSA-44 | 2,420 bytes | 1,312 bytes |
若直接將 X.509 憑證的簽名換成 ML-DSA，每次 TLS 握手需要額外傳輸約 3.7 KB 的簽名與公鑰資料，對大量短連線場景衝擊顯著。MTC 的解法是批次處理：將多張憑證的資訊合入一棵 Merkle 樹，只對樹根簽一次，每張憑證攜帶的是 Merkle 路徑而非獨立簽名，平攤後每張憑證增加的位元組數大幅減少。
ML-DSA 演算法細節
ML-DSA（Module Lattice-based Digital Signature Algorithm，原稱 CRYSTALS-Dilithium）於 2024 年由 NIST 正式標準化為 FIPS 204。ML-DSA-44 是三個安全等級中最低的（等同 AES-128 的安全強度）：
- 私鑰大小：2,560 bytes
- 公鑰大小：1,312 bytes
- 簽名大小：2,420 bytes
- 簽名時間：約 0.1 ms（現代 CPU）
- 安全假設：格密碼學（Lattice-based），目前量子電腦無已知有效攻擊
移轉時間線
- 2026 年底：Let's Encrypt 建立 MTC staging 環境，ACME client 開發者可開始測試
- 2027 年：MTC 正式生產，與現有 X.509 並行發行
- 2029 年：Google 目標完成旗下服務的後量子移轉
- 2030–2035：NSA、NIST、歐盟政府機構強制要求後量子標準
對現有使用者而言，當前無需任何操作——MTC 將透過 ACME 自動提供，現有憑證繼續有效。Let's Encrypt 同時強調：後量子金鑰交換比後量子簽名更緊迫，建議伺服器立即啟用 X25519MLKEM768 混合金鑰交換，這不需要等待 MTC 的推出。
原始來源：Let's Encrypt — A Post-Quantum Future、IETF PLANTS Working Group
聲音攻擊：Sound Blaster Katana V2X 因未授權 Bluetooth 韌體更新通道淪為 BadUSB 載體
nns.ee · 2026-06-03
研究員 Hannu Laulainen 於 2026 年 6 月 3 日發布完整揭露報告，說明如何透過 Creative Sound Blaster Katana V2X 聲霸（USB 連接的 PC 音響）在無需配對、無需接觸目標電腦的前提下，對連接的 PC 執行任意指令。漏洞鏈由三個弱點串接：未授權的 Bluetooth CTP 通道、無簽名驗證的韌體更新機制，以及裝置現有的 USB HID 鍵盤基礎設施。
漏洞機制
Creative 的私有協議 CTP（Creative Transport Protocol） 負責裝置管理，包含韌體更新指令。CTP 透過 USB 傳輸時有挑戰-回應認證機制，但 CTP 處理器被橋接至 USB 與 Bluetooth 兩個通道。Bluetooth 通道沒有配對要求、沒有認證、沒有加密——任何在 15 公尺範圍內的設備都可以直接發送 CTP 韌體更新指令。
第二個漏洞：韌體容器（FW Container）只包含一個 SHA-256 CHK2 checksum 作為完整性驗證——這是可被研究員任意重新計算的哈希值，並非不可偽造的數位簽名。攻擊者可修改韌體後更新 checksum，裝置照單全收。
BadUSB 路徑
Katana V2X 原本就實作了 USB HID 介面用於多媒體鍵盤按鍵（音量、播放控制）。研究員的 PoC 是 185 bytes 的韌體 patch：修改 USB HID 描述符讓裝置在 PC 端顯示為標準鍵盤，加入手寫 ARM Thumb 組合語言，在開機時自動注入一段按鍵序列（PoC 為 echo pwned，實際攻擊可替換為任意 payload）。整個攻擊流程：
- 攻擊者透過 Bluetooth 連線至目標音響（無需配對）
- 發送惡意韌體更新指令
- 裝置重啟後以新 USB HID 身分連接 PC
- 執行鍵盤注入 payload
受影響版本與廠商回應
受影響型號：Creative Sound Blaster Katana V2X（以及可能使用相同韌體架構的同系列型號）。研究員已按負責任揭露流程通知 Creative；廠商拒絕承認此問題屬於資安風險，未發布修補韌體。截至 2026 年 6 月，漏洞仍未修補。使用者可考慮的緩解措施：停用裝置的 Bluetooth 功能、或在不使用時拔除 USB 連線。
原始來源：Pwnd Blaster: Hacking your PC using your speaker without ever touching it
完整揭露：VSCode Webview 鍵盤事件注入漏洞允許 1 次點擊竊取 github.dev OAuth Token
Ammar Askar Security Research · 2026-06-03
安全研究員 Ammar Askar 於 2026 年 6 月 3 日發布完整揭露，說明如何透過惡意 Jupyter Notebook 在 github.dev（VSCode Web 版）上執行一次點擊後竊取使用者的 GitHub OAuth Token。微軟已於同日推出緩解措施（確認對話框），完整修補仍在進行中。
漏洞機制
核心弱點是 VSCode webview 的鍵盤事件冒泡（keydown event bubbling）：webview 中的 JavaScript 可以模擬 KeyboardEvent 並讓它冒泡至主應用程式，等效於「程式碼以使用者身分按下鍵盤」。VSCode 未對 webview 觸發的鍵盤事件與真實鍵盤事件進行區分。
攻擊鏈由四個步驟組成：
- Jupyter Markdown 注入：惡意
.ipynb的 Markdown cell 包含<img onerror="...">，在渲染時執行 JavaScript，觸發Ctrl+Shift+A鍵盤事件接受 VSCode 的「安裝推薦延伸套件」通知 - 安裝本機工作區延伸套件：惡意 notebook 的 repo 根目錄下預置了
.vscode/extensions/malicious-ext/，被接受後自動安裝（trusted workspace 繞過了出版者驗證） - 透過自訂 keybinding 安裝第二個遠端延伸套件：本機延伸套件在
package.json中定義自訂鍵盤快捷鍵，觸發 VSCode 指令安裝攻擊者控制的遠端延伸套件 - 存取 localStorage Token：遠端延伸套件有足夠權限透過 VSCode Extension API 存取 github.dev 的
localStorage，取得 GitHub OAuth Token，並以https://api.github.com/user/repos驗證並列舉私有 repository
修補與緩解
微軟的緩解措施（2026-06-03）：在 Web VSCode 開啟 Notebook 時加入確認對話框，以及阻止命令繞過可信出版者要求。根本修補（區分 webview 與真實使用者的鍵盤事件）需要更大範圍的架構調整，時間表尚未公開。
原始來源：Full Disclosure: 1-Click GitHub Token Stealing via a VSCode Bug