1 ポイント 投稿者 GN⁺ 2025-06-11 | 1件のコメント | WhatsAppで共有
  • ニュースリーダーアプリのユーザーとジャーナリストが、匿名性否認可能性を保ちながら安全にやり取りできるようにするオープンソースのセキュアメッセージングソリューション
  • すべてのユーザーデバイスがランダムな暗号化トラフィックを生成するため、メッセージを送受信していても通常のニュース利用とネットワーク上で区別されない
  • メッセージは二重に暗号化され、同一のサイズ・頻度で処理されるため、デバイス押収時にも証拠を残さない
  • モバイルアプリ、クラウドAPI、セキュアサーバー、ジャーナリスト向けデスクトップクライアントなど、完全なエンドツーエンド構成で成り立っている
  • 透明性のあるオープンソース開発、強力な暗号技術、ニュース組織の要件に最適化された特化機能が既存プロジェクトに対する利点

CoverDrop の紹介

  • CoverDrop は、ニュース企業のモバイルアプリ利用者が記者に秘密裏かつ追跡不能にメッセージを送れるよう設計された安全なシステム
  • このシステムは強力な否認可能性を提供し、アプリがセキュア通信に使われているのか通常のニュース閲覧に使われているのかをネットワーク解析者が見分けられないようにする

主要構成要素

  • ニュースアプリ内モジュール: ユーザーのモバイルアプリに統合
  • クラウド API: 中央接点として機能
  • CoverNode: 安全な場所で動作するサービス群
  • ジャーナリスト向けデスクトップアプリケーション: 記者が使う PC 向けクライアント

この4つから成る構成がエンドツーエンド暗号化強力なセキュリティを実現する

動作方式

  • ニュースアプリのすべてのインスタンスが定期的に**小さな暗号化データ("cover メッセージ")**をサーバーと交換する
  • 実際の情報提供(ソースメッセージ)も通常の cover メッセージと完全に同一の形で暗号化・送信される。ネットワーク上では区別できない
  • すべてのメッセージは同一のサイズ・周期で処理され、Kinesis ストリームへ送られて処理される
  • サーバーで一次復号と本物のメッセージ判定が行われ、dead drop 形式で記者クライアントに配信される。padding によって dead drop のサイズは均一に保たれる
  • 記者は自分の公開鍵で暗号化されたメッセージだけを最終的に復号できる
  • メッセージ保管領域は平時から暗号化された状態で、デバイス押収時にも実際に会話があったかを証明できない
  • 記者が返信する際も、同様の方式で暗号化通信と鍵交換が行われる

より詳細な設計とアルゴリズム構造は、ケンブリッジ大学コンピュータサイエンス学部と共同作成した ホワイトペーパー で確認できる

セキュリティポリシー

  • CoverDrop のセキュリティは最優先
  • 完全な安全性は不可能であることを認め、セキュリティ研究者からの報告を歓迎
  • メッセージの機密性・完全性・ネットワーク匿名性・否認可能暗号化に関する問題は継続的に改善すべき領域
  • 統合ニュースアプリ内の他要素によるサイドチャネル問題も積極的に改善中

暗号化ソフトウェア利用時の注意

  • CoverDrop には暗号化ソフトウェアが含まれる
  • 各国の暗号技術の輸入・利用・再輸出に関する法令の遵守が必要
  • 米国商務省 BIS 分類: ECCN 5D002.C.1(非対称暗号を含むソフトウェア)
  • このオープンソース配布は輸出例外規定(TSU, §740.13)の対象

ライセンス

  • CoverDrop リポジトリはApache License 2.0で提供される

1件のコメント

 
GN⁺ 2025-06-11
Hacker Newsのコメント
  • もう少し説明が必要な人には、https://www.coverdrop.org/ のメインサイトが参考情報を提供する目的に適しているように感じる。イギリスの公式機密法 1920 は新聞社との匿名連絡を保護していたが、その後の法改正でこの部分が消えたのは残念に思える。

  • 多くの報道機関が https://securedrop.org/ を使っているが、CoverDrop がどう違い、どこが優れているのか気になる。対応している報道機関のディレクトリは https://securedrop.org/directory/ で確認できる。

    • 論文でもすでに触れられているが、SecureDrop と CoverDrop はやや異なる状況に焦点を当てている点が違いだ。SecureDrop は TOR を使うが、これはネットワークレベルや端末上で検知され得るため、状況によっては TOR を使ったという事実だけで内部告発者の身元が露見する危険がある。一方で、ニュースアプリのインストールはそれほど不審に見えない状況を作りやすい。CoverDrop は、初心者ユーザーが露見せずに最初の連絡を取るのに向いている。ネットワークトラフィックは通常ユーザーと区別できず、アプリのストレージは実際の利用有無に関係なく容量を占有し、否認可能性を提供する。CoverDrop は SecureDrop のように大きなファイルを送れず、論文では必要に応じて記者が CoverDrop のメッセージ内で SecureDrop を安全に使う方法を案内すると提案している。そのため、セキュリティ意識と技術力が十分なら、最初から SecureDrop に行くほうが簡単な選択かもしれない。

    • SecureDrop は素晴らしく、The Guardian でも今後も継続して活用する予定だ。SecureDrop との大きな違いは、Tor Browser をインストールせずに匿名性を確保できる点で、この機能をニュースアプリ内に組み込むことで、非技術者の内部告発者にとってのハードルが大幅に下がる。基本的に良い OPSEC の実現を支援してくれる。CoverDrop(Secure Messaging)にはまだ制約があり、まずプロトコルの特性上、文書のアップロードができず、1日に送れるのは数 KB に限られる。現時点では、記者が状況に応じてユーザーを Signal に案内できる。記者が先に情報源の身元と脅威を評価したうえで Signal の番号を渡すため、危険を一段階ふるいにかけられる良い構造だ。今後は、CoverDrop システム内でリスク評価を行った後、匿名性の毀損を最小限に抑えつつ文書アップロード用リンクを送る機能も検討している。たとえば、暗号化されたメール添付ファイルのように偽装する方式などが議論されている。参考論文 もある。もう一つの制約は、このシステムの匿名性がアプリの大規模利用に依存している点で、小規模なニュースエージェンシーが導入するとこの特性は弱くなり得る。それでも実際には、否認可能なストレージ構造だけでも、他の内部告発手段(PGP、Tor ベースなど)に比べれば大きな前進だという見方だ。ただし、自分だけがこのアプリを使っている場合でもかなり安全である点は前向きな要素に思える。

    • ホームページの FAQ にも同じ質問がある。

  • このアイデアは本当に気に入った。昔 CIA がスター・ウォーズのファンサイトなどで作っていた秘密通信システムを思い出した。The Guardian は明示的には触れていないが、実際このアプリもそうしたカバーストーリーとして設計されている点で、ニュースアプリという偽装は本当に優れたアプローチだと思う。個人的に一つ助言を加えるなら、このアプリでリークを計画するなら、いつでも調査対象になり得る端末では使いたくないということだ。たとえば会社支給の業務用スマホがそうだろう。Guardian アプリをインストールすること自体は問題でなくても、実際に組織内調査で Guardian に重要ニュースが流れた場合、次のように対象を絞り込まれる懸念がある。1. そもそもその情報にアクセスできた人員 2. その中で当該アプリをインストールしていた、ダウンロード履歴がある、または端末提出を拒否する人員。小規模なグループだけが知る情報を流出させる場合や、端末が実利用者に結び付いている場合は、他人(家族など)の端末を使って露見リスクを最小化したほうがよい。実際の目標は調査で疑われないことであり、このアプリと提供した情報が Guardian の報道に直結し得ることを考えると、技術的に安全でも完璧なカバーストーリーにするのは難しい。最後の推奨としては、自分と結び付きにくい端末を使うほうが、情報漏えい時により大きな安全性をもたらす。この点が脅威モデルに明記されていないため、追加の被害者が生じる可能性があることにも触れている。

    • プロジェクトの技術リードとしてコメントする。業務用スマホを使うべきではないという点には同意するし、特に多くの業務用端末には、事実上スパイウェアのようなモバイル管理ソリューション(MDM)が含まれていることが多い。匿名集団の規模が小さいと、技術的アプローチだけでは限界があることも再確認した。アプリ利用を内部告発の場面でも十分に否認できるよう、多くの努力を払っている。データは「公開」と「非公開」のストレージに分けられ、非公開データは固定サイズの暗号化ストレージに保存され、ケンブリッジのチームメンバーが開発した KDF 技法(リンク)で保護される。しかし、端末にスパイウェアが入っていれば、こうした努力も無意味になり得るのが現実だ。内部でもこのリスクは認識して議論しており、FAQ の説明もさらに補強する予定だ。特に MDM 利用への警告を明確に記載する方向で、近いうちに更新する計画がある。加えて、root 化された端末やデバッグモードの端末を検知して警告する機能も搭載している。MDM の検知はいたちごっこのため、ユーザーがそもそも業務用端末を使わないことが最も望ましい対策だという考えだ。
  • いつ正式リリースになるのか、Obtainium に登録したいというスケジュールの質問。

    • このプロジェクトはライブラリの形なので、登録に向いているかはよく分からない。実際に登録対象になるのはこれを使うアプリのはずで、現時点では Guardian アプリが唯一の例のようだ。今後 Guardian チームが Play Store 以外で配布する計画があるかどうか、返答を待っている。