Black Hat USA 2025 | Practical Attacks on Nostr, a Decentralized Censorship-Resistant Protocol

NOSTR 是一套以「去信任化」為核心設計理念的去中心化社群協議，用戶以公私鑰對作為唯一身份，不綁定任何服務器，任何人都能架設轉播節點（Relay）。正因如此，身份驗證的責任從服務器端完全轉移到客戶端，這雖帶來了抗審查的自由，卻也製造了一個龐大的攻擊面。來自日本 NICT 等機構的研究團隊決定系統性地審視這個協議在密碼學設計與客戶端實作兩個維度上的安全現況。

研究團隊分析了 56 個 NOSTR 客戶端並深入剖析其中 9 個，發現多數客戶端在接收事件時直接跳過簽名驗證。NOSTR 規範（NIP-01）定義了每個事件必須以私鑰簽名，但規範並未強制要求服務器拒絕未經驗證的事件——服務器做簽名檢查只是為了防止垃圾訊息，保護的是自身存儲，而非客戶端安全。因此，攻擊者可直接對中繼節點注入偽造事件，偽裝成任意用戶發布貼文或個人資料（例如替換比特幣收款地址），接收端客戶端若未驗證簽名則完全無法察覺。更複雜的情況是，即便客戶端實作了驗證邏輯，也可能因為事件 ID 快取機制而被繞過：攻擊者先讓受害者快取一個合法事件，再發送具有相同 ID 但竄改內容的偽造事件，快取命中後驗證函數直接回傳「已驗證」，跳過真正的密碼學檢查。

加密私訊（NIP-04）的問題源自協議設計層面的根本缺陷。NIP-04 採用 AES-CBC 加密，但 CBC 模式本身不提供密文完整性保護，這使得攻擊者在不知道金鑰的情況下，仍能透過翻轉初始向量中的特定比特，精確地操控解密後明文的對應位元——例如將「匯款給 Alice 的比特幣地址」改成攻擊者自己的地址。然而 CBC bit-flipping 的輸出是隨機可控但需要明文配合，因此研究者進一步利用跨協議攻擊：NOSTR 的設備遷移協議（Nsec Bunker）在兩台設備建立配對時，會以相同的會話金鑰加密非元數據（non-metadata），攻擊者可從中取得已知明文與密文的配對，再利用此配對向私訊通道注入偽造內容。

第三類攻擊將客戶端的鏈接預覽功能武器化。主流 NOSTR 客戶端（包含多個 iOS/Android app）在收到含 URL 的私訊後，會在本地自動向該 URL 發起 HTTP 請求抓取預覽元數據。攻擊者先取得加密密文，透過 CBC bit-flipping 將 URL 的網域部分從 `example.net` 翻轉為攻擊者控制的 `attacker.net`，而 URL 的秘密路徑部分（如會議邀請 token）在解密後仍保持原樣，並隨預覽請求原封不動地送到攻擊者伺服器。若攻擊者想還原更多明文，則可逐字元暴力猜測：假設訊息以 `https` 開頭，攻擊者對每個可能字元構造修改後的密文，觀察客戶端是否對特定伺服器發出預覽請求作為 oracle 訊號，即可逐步還原整段加密訊息——即便底層加密演算法本身完全安全也無法阻止此攻擊。

研究者在與開發者合作兩年後提出三項根本性建議：首先，協議規範（NIPs）必須明確要求客戶端進行簽名驗證，不只定義如何簽名，更要定義驗證義務；其次，不同用途必須使用獨立金鑰，身份金鑰與訊息加密金鑰不可混用；第三，加密私訊必須改用帶有完整性保護的認證加密（如 AES-GCM），徹底消除密文可延展性問題。研究者也特別指出，去中心化系統的修補困境在於沒有單一部署入口，修補需要數十個社群、數百個客戶端各自更新，這進一步強調「從設計階段就做對」的重要性。