Q1. セッションの起源ストーリーと、分散型メッセージングネットワークを構築する動機について簡単に説明していただけますか？Sessionは、世界中の何百人もの貢献者による共同制作です。これがオープンソースソフトウェアの美しさです。誰でもコードを書いてSessionのコードベースに貢献できます。しかし、すべての製品には、より中心的な創設の物語があります。Sessionの場合、元の創設者たちは新たに確立された分散型ネットワークの上に概念実証アプリケーションを構築したいと考えていました。私たちは、メッセージをこの分散型ネットワークを通じて保存し、ルーティングするメッセージングアプリケーションを構築することが最良の概念実証アプリケーションであると考えました。なぜなら、基本的なメッセンジャーがあれば、この概念を他の多くのアプリケーションに一般化できるからです。これらのアプリケーションはしばしば、あるデバイスから別のデバイスへメッセージを渡すことに帰着します。Sessionは別の名前で立ち上げられ、すぐに成長しました。Sessionに焦点を当てるべきだということが明らかになり、元々は概念実証として設計されていたものが、今日利用可能な最大のプライベートメッセージングアプリケーションの一つに成長しました。Q2. 最近のCISAの緊急指令では、TM SGNLに2つの重大な欠陥が特定されました。あなたの視点から見ると、攻撃者がチャットログやメタデータを収集できるようにした設計または実装のどこに問題があったのでしょうか？これは、カスケーディング設計と実装の問題の典型的なケースであり、それ自体では悪用できないかもしれませんが、組み合わさることでネットワークのセキュリティに壊滅的な失敗を引き起こす可能性があります。最初の失敗は設計にありました。TeleMessageは、著名なセキュアメッセージングアプリケーションであるSignalを取り入れ、監査ログを作成する目的でアプリに意図的なバックドアを追加しました。この監査ログの機能は、ユーザーが送信したすべてのメッセージのコピーを、エンドツーエンドで暗号化される前に、単一の中央サーバーに送信することによって機能しました。そのサーバーは、これらすべてのメッセージのコピーを暗号化されていない状態で保存しました。これにより、極めて機密性の高いデータの攻撃者にとってのハニーポットが作成されました。ハッカーにとって魅力的な国家安全保障情報の宝の山です。二回目の失敗は、TM SGNL アーカイブサーバー上で実行されていたサービス (Spring Boot Actuator) の設定ミスでした。これは、開発者がバグを診断するために通常使用する URL が認証なしで誰でも使用できるように開放されてしまった非常に基本的な設定ミスの問題です。これにより、攻撃者はサーバーのメモリをダンプすることができ、そのダンプには暗号化されていないメッセージやユーザーの認証情報が平文で表示され、ハッカーがメッセージやアカウント情報を回収できるようになりました。この規模のハッキングが発生するためには、両方の失敗が共存する必要があることに注意することが重要です。サイバーセキュリティの侵害では、攻撃者が単一の設計や実装の欠陥を見つけ、その欠陥を利用して他の脆弱性を見つけて悪用することが多いです。Q3. E2EEクライアント、特にSignal互換のものがそのような弱点を導入することはどのくらい一般的ですか、そしてなぜこれらはもっと早く見つからないのですか？WhatsApp、Signal、Telegramのような一般的な消費者向けメッセージングアプリケーションは、通常、TeleMessageサーバーよりもサーバー周辺のセキュリティがはるかに優れています。しかし、監査ログを作成するために明示的に開発および修正されたメッセージングアプリケーションに関しては、この種の誤設定が見られることがより一般的です。特に、これらのアプリケーションがクローズドソースコードである場合、コミュニティのセキュリティ研究者はコードの弱点を分析する能力が同じではないため、一般的な誤設定が長い間発見されなかったり、国家レベルのハッカーによって秘密にされ、修正されないバックドアがシステムに維持されたりすることがあります。Q4. あなたは、単一のベンダーがスタックの重要な部分を制御している限り、固有のリスクがあると主張しています。ベンダーの中央集権化は、実世界のプライバシーの失敗にどのように結びつくのでしょうか？ベンダーの中央集権化は、通常、クローズドソースコードと中央サーバーと組み合わされています。メッセージングサービスがすべてのユーザーのメッセージを単一の中央位置に保存すると、攻撃者にとってのハニーポットが作成されます。彼らは、単一のサーバーを侵害することでサービスを介して送信されたすべてのメッセージにアクセスできることを知っています。オープンソースのセキュリティ研究者や監査人がレビューできないクローズドソースコードと組み合わされると、攻撃者のインセンティブは増加し、発見されるはずのバグは、これらのバグをプライベートに保ってバックドアアクセスを持続させる最も洗練された攻撃者以外には認識されません。これにより、サービスのすべてのユーザーが侵害されてしまいます。Q5. TM SGNL(の外で、ベンダー側の欠陥がエンドツーエンド暗号化の保証を損なった例を共有していただけますか？)SignalがSMS認証のためにTwilioを使用した結果、Twilioがハッキングされた際に一部のSignalユーザーのアカウントが危険にさらされました。SMS認証はSignalユーザーがアカウントを回復する方法の一つであるため、Twilioがハッキングされた際、攻撃者はSignalサーバーを欺いてSignalユーザーの電話番号を所有していると信じ込ませ、アカウントを回復することができました。このアクセスを利用して、これらのSignalユーザーのアカウントから無許可のメッセージを送信しました。Q6. なぜ分散化が単一ベンダーリスクを完全に軽減する唯一の方法だと考えますか？分散化は、単一ベンダーリスクを完全に軽減する唯一の方法です。なぜなら、分散化は中央集権的なシステムに内在する単一の失敗点を取り除くからです。単一のエンティティがスタックの重要な部分を制御している場合（ユーザーのアイデンティティからメッセージのルーティングやストレージまで）、彼らは攻撃者にとって魅力的なターゲットとなり、その設計や実装の欠陥はTM SGNLで見られるように、壊滅的な結果をもたらす可能性があります。分散型ネットワークでは、侵害される中央サーバーは存在せず、バックドアを挿入するよう圧力をかけられる単一の企業もなく、メタデータ収集のためにターゲットにされる唯一のデータベースもありません。ユーザーのアイデンティティは、中央機関に結びついた実世界の識別子ではなく、しばしば暗号鍵です。メッセージは、独立したノードの分散ネットワーク全体にルーティングおよび保存されるため、どのノードも送信者と受信者のIPアドレスの両方を見ることはなく、単一のエンティティが通信の包括的なログを収集することはできません。この権力とデータの分配は、システムを攻撃、検閲、データの悪用に対して本質的によりレジリエントにします。なぜなら、利用される単一のボトルネックが存在しないからです。セキュリティは一つの企業の信頼性に依存するのではなく、分散ネットワークの集合的な誠実さと頑健な暗号設計に依存しています。Q7. セッションはサービスノードのネットワークを使用します。このアーキテクチャは、どのようにして一方の当事者がユーザーデータを危険にさらすことを防ぐのでしょうか？従来のメッセージングアプリとは異なり、Sessionはすべてのユーザーデータを保存する単一の中央サーバーに依存していません。代わりに、メッセージは数千の独立したコミュニティ運営のSessionノードからなる分散ネットワークを通じてルーティングされます。これにより、単一の集中型データベースの「ハニーポット」効果が排除され、特定の組織が包括的な暗号化メッセージとメタデータを収集することが非常に困難になります。Sessionノードはオフラインの受信者のためにメッセージを一時的に保存します。ただし、これらのメッセージはエンドツーエンドで暗号化されており、ノード自体はコンテンツを読むことができません。さらに、メッセージは限られた時間(Time-To-Live)のみ保存され、読まれた後は削除可能であり、ノードネットワーク上での長期的な保持を防ぎます。さらに、SessionはTorに似た修正されたオニオンルーティング技術を採用しています。メッセージを送信すると、それは層で暗号化され、各層は連続するSessionノードによって剥がされます。重要なのは、どのノードも送信者と受信者のIPアドレスの両方を知らないということです。これにより、ノードが侵害されたとしても、メッセージをその発信元や宛先に結びつけることはできません。セッションアカウントは、電話番号やメールアドレスなどの個人情報を必要とせずに暗号的に生成されます。これにより、セッションアカウントIDに関連付けられた実世界のアイデンティティが存在せず、プライバシーがさらに強化され、外部データ侵害を通じてユーザーのアイデンティティを危険にさらすことがより困難になります。この多層的アプローチは、中央制御ポイントがなく、一時的なストレージ、エンドツーエンドの暗号化、匿名化されたルーティングを備えているため、少数のセッションノードが侵害されても、ネットワーク全体の整合性とプライバシーは保たれます。Q8. TM SGNLが連邦機関に展開されていることを考えると、政府は本当に分散型のメッセージングに向かうと思いますか？そのシフトに対してどのような障壁がありますか？それは難しい問題です。政府機関は通常、監査ログが作成され、監査人が閲覧できるように保存されることを要求します。これにより、固有のセキュリティ脆弱性が生じます。エンドツーエンドの暗号化は、会話の参加者だけが通信の内容を見るべきであるように設計されています。監査要件は、エンドツーエンドの暗号化に意図的なバックドアを導入し、安全に実装することが難しくなります。しかし、これをより適切に管理する方法があります。例えば、監査ログは常に静止状態で暗号化されて保存されるべきであり、その監査ログにアクセスできるユーザーに対しては堅牢な保護が必要です。政府は簡単に監査できるオープンソースツールを使用し、監査ログがどのように保存され、どのサーバーに保存されるかについて非常に慎重に考えるべきです。もし規制が更新されれば、分散型ソリューションが政府のコミュニケーションでより良く活用される方法を提供する可能性があります。Q9. セキュリティを重視する組織に、Signal互換のプロプライエタリクライアントからSessionへの移行を促すには、どのように説得しますか？TM SGNLのハッキングは、ユーザーがセキュリティとプライバシー機能が大幅に強化されたSessionのようなオープンソースツールに移行するための最も明確なインセンティブを提供していると思います。将来的には、組織がSessionのようなオープンソースツールを利用して、それらのツールに接続できる独自の監査ツールを開発することが可能かもしれません。しかし、そのような監査ソリューション自体もオープンソースであり、監査可能であるべきです。そうしないと、TM SGNLと同じ問題が再発することは避けられません。Q10. 今後12〜18ヶ月の間に、Sessionのロードマップにはどのような主要な機能や改善が予定されていますか？最終的に、Sessionと安全でプライベートなメッセージング全体に対する長期的なビジョンは何ですか？Sessionの現在の焦点は、より多くのユーザーにリーチすることです。Sessionはすでに月間アクティブユーザーが100万人を超えていますが、私たちは、アプリケーション設計の中心に強力なプライバシーとセキュリティを組み込んだソリューションを選ぶユーザーがさらに増えることを望んでいます。Sessionの貢献者たちは、Sessionのパワーユーザー向けのプレミアム機能のスイートに取り組んでおり、Sessionエコシステムへの持続可能な資金提供を可能にしています。これには、より大きなグループ、より多くのプロフィールのカスタマイズ機能、増加したファイルサイズなど、Sessionのユーティリティを高めるすべての機能が含まれています。より広く言えば、私はSessionを、コンテンツとメタデータのプライバシーを非常に消費しやすく使いやすい体験の中で提供する唯一のアプリと見ています。そして、データ侵害がユーザーに影響を与え続ける中、Sessionは今後12～18ヶ月の間に成長し続けると思います。
安全なメッセージングの再発明：セッション共同創設者キージェフリーズとの深堀り
Q1. セッションの起源ストーリーと、分散型メッセージングネットワークを構築する動機について簡単に説明していただけますか？
Sessionは、世界中の何百人もの貢献者による共同制作です。これがオープンソースソフトウェアの美しさです。誰でもコードを書いてSessionのコードベースに貢献できます。しかし、すべての製品には、より中心的な創設の物語があります。Sessionの場合、元の創設者たちは新たに確立された分散型ネットワークの上に概念実証アプリケーションを構築したいと考えていました。私たちは、メッセージをこの分散型ネットワークを通じて保存し、ルーティングするメッセージングアプリケーションを構築することが最良の概念実証アプリケーションであると考えました。なぜなら、基本的なメッセンジャーがあれば、この概念を他の多くのアプリケーションに一般化できるからです。これらのアプリケーションはしばしば、あるデバイスから別のデバイスへメッセージを渡すことに帰着します。Sessionは別の名前で立ち上げられ、すぐに成長しました。Sessionに焦点を当てるべきだということが明らかになり、元々は概念実証として設計されていたものが、今日利用可能な最大のプライベートメッセージングアプリケーションの一つに成長しました。
Q2. 最近のCISAの緊急指令では、TM SGNLに2つの重大な欠陥が特定されました。あなたの視点から見ると、攻撃者がチャットログやメタデータを収集できるようにした設計または実装のどこに問題があったのでしょうか？
これは、カスケーディング設計と実装の問題の典型的なケースであり、それ自体では悪用できないかもしれませんが、組み合わさることでネットワークのセキュリティに壊滅的な失敗を引き起こす可能性があります。
最初の失敗は設計にありました。TeleMessageは、著名なセキュアメッセージングアプリケーションであるSignalを取り入れ、監査ログを作成する目的でアプリに意図的なバックドアを追加しました。この監査ログの機能は、ユーザーが送信したすべてのメッセージのコピーを、エンドツーエンドで暗号化される前に、単一の中央サーバーに送信することによって機能しました。そのサーバーは、これらすべてのメッセージのコピーを暗号化されていない状態で保存しました。これにより、極めて機密性の高いデータの攻撃者にとってのハニーポットが作成されました。ハッカーにとって魅力的な国家安全保障情報の宝の山です。
二回目の失敗は、TM SGNL アーカイブサーバー上で実行されていたサービス (Spring Boot Actuator) の設定ミスでした。これは、開発者がバグを診断するために通常使用する URL が認証なしで誰でも使用できるように開放されてしまった非常に基本的な設定ミスの問題です。これにより、攻撃者はサーバーのメモリをダンプすることができ、そのダンプには暗号化されていないメッセージやユーザーの認証情報が平文で表示され、ハッカーがメッセージやアカウント情報を回収できるようになりました。
この規模のハッキングが発生するためには、両方の失敗が共存する必要があることに注意することが重要です。サイバーセキュリティの侵害では、攻撃者が単一の設計や実装の欠陥を見つけ、その欠陥を利用して他の脆弱性を見つけて悪用することが多いです。
Q3. E2EEクライアント、特にSignal互換のものがそのような弱点を導入することはどのくらい一般的ですか、そしてなぜこれらはもっと早く見つからないのですか？
WhatsApp、Signal、Telegramのような一般的な消費者向けメッセージングアプリケーションは、通常、TeleMessageサーバーよりもサーバー周辺のセキュリティがはるかに優れています。しかし、監査ログを作成するために明示的に開発および修正されたメッセージングアプリケーションに関しては、この種の誤設定が見られることがより一般的です。特に、これらのアプリケーションがクローズドソースコードである場合、コミュニティのセキュリティ研究者はコードの弱点を分析する能力が同じではないため、一般的な誤設定が長い間発見されなかったり、国家レベルのハッカーによって秘密にされ、修正されないバックドアがシステムに維持されたりすることがあります。
Q4. あなたは、単一のベンダーがスタックの重要な部分を制御している限り、固有のリスクがあると主張しています。ベンダーの中央集権化は、実世界のプライバシーの失敗にどのように結びつくのでしょうか？
ベンダーの中央集権化は、通常、クローズドソースコードと中央サーバーと組み合わされています。メッセージングサービスがすべてのユーザーのメッセージを単一の中央位置に保存すると、攻撃者にとってのハニーポットが作成されます。彼らは、単一のサーバーを侵害することでサービスを介して送信されたすべてのメッセージにアクセスできることを知っています。オープンソースのセキュリティ研究者や監査人がレビューできないクローズドソースコードと組み合わされると、攻撃者のインセンティブは増加し、発見されるはずのバグは、これらのバグをプライベートに保ってバックドアアクセスを持続させる最も洗練された攻撃者以外には認識されません。これにより、サービスのすべてのユーザーが侵害されてしまいます。
Q5. TM SGNL(の外で、ベンダー側の欠陥がエンドツーエンド暗号化の保証を損なった例を共有していただけますか？)
SignalがSMS認証のためにTwilioを使用した結果、Twilioがハッキングされた際に一部のSignalユーザーのアカウントが危険にさらされました。SMS認証はSignalユーザーがアカウントを回復する方法の一つであるため、Twilioがハッキングされた際、攻撃者はSignalサーバーを欺いてSignalユーザーの電話番号を所有していると信じ込ませ、アカウントを回復することができました。このアクセスを利用して、これらのSignalユーザーのアカウントから無許可のメッセージを送信しました。
Q6. なぜ分散化が単一ベンダーリスクを完全に軽減する唯一の方法だと考えますか？
分散化は、単一ベンダーリスクを完全に軽減する唯一の方法です。なぜなら、分散化は中央集権的なシステムに内在する単一の失敗点を取り除くからです。単一のエンティティがスタックの重要な部分を制御している場合（ユーザーのアイデンティティからメッセージのルーティングやストレージまで）、彼らは攻撃者にとって魅力的なターゲットとなり、その設計や実装の欠陥はTM SGNLで見られるように、壊滅的な結果をもたらす可能性があります。
分散型ネットワークでは、侵害される中央サーバーは存在せず、バックドアを挿入するよう圧力をかけられる単一の企業もなく、メタデータ収集のためにターゲットにされる唯一のデータベースもありません。ユーザーのアイデンティティは、中央機関に結びついた実世界の識別子ではなく、しばしば暗号鍵です。メッセージは、独立したノードの分散ネットワーク全体にルーティングおよび保存されるため、どのノードも送信者と受信者のIPアドレスの両方を見ることはなく、単一のエンティティが通信の包括的なログを収集することはできません。
この権力とデータの分配は、システムを攻撃、検閲、データの悪用に対して本質的によりレジリエントにします。なぜなら、利用される単一のボトルネックが存在しないからです。セキュリティは一つの企業の信頼性に依存するのではなく、分散ネットワークの集合的な誠実さと頑健な暗号設計に依存しています。
Q7. セッションはサービスノードのネットワークを使用します。このアーキテクチャは、どのようにして一方の当事者がユーザーデータを危険にさらすことを防ぐのでしょうか？
従来のメッセージングアプリとは異なり、Sessionはすべてのユーザーデータを保存する単一の中央サーバーに依存していません。代わりに、メッセージは数千の独立したコミュニティ運営のSessionノードからなる分散ネットワークを通じてルーティングされます。これにより、単一の集中型データベースの「ハニーポット」効果が排除され、特定の組織が包括的な暗号化メッセージとメタデータを収集することが非常に困難になります。Sessionノードはオフラインの受信者のためにメッセージを一時的に保存します。ただし、これらのメッセージはエンドツーエンドで暗号化されており、ノード自体はコンテンツを読むことができません。さらに、メッセージは限られた時間(Time-To-Live)のみ保存され、読まれた後は削除可能であり、ノードネットワーク上での長期的な保持を防ぎます。
さらに、SessionはTorに似た修正されたオニオンルーティング技術を採用しています。メッセージを送信すると、それは層で暗号化され、各層は連続するSessionノードによって剥がされます。重要なのは、どのノードも送信者と受信者のIPアドレスの両方を知らないということです。これにより、ノードが侵害されたとしても、メッセージをその発信元や宛先に結びつけることはできません。
セッションアカウントは、電話番号やメールアドレスなどの個人情報を必要とせずに暗号的に生成されます。これにより、セッションアカウントIDに関連付けられた実世界のアイデンティティが存在せず、プライバシーがさらに強化され、外部データ侵害を通じてユーザーのアイデンティティを危険にさらすことがより困難になります。
この多層的アプローチは、中央制御ポイントがなく、一時的なストレージ、エンドツーエンドの暗号化、匿名化されたルーティングを備えているため、少数のセッションノードが侵害されても、ネットワーク全体の整合性とプライバシーは保たれます。
Q8. TM SGNLが連邦機関に展開されていることを考えると、政府は本当に分散型のメッセージングに向かうと思いますか？そのシフトに対してどのような障壁がありますか？
それは難しい問題です。政府機関は通常、監査ログが作成され、監査人が閲覧できるように保存されることを要求します。これにより、固有のセキュリティ脆弱性が生じます。エンドツーエンドの暗号化は、会話の参加者だけが通信の内容を見るべきであるように設計されています。監査要件は、エンドツーエンドの暗号化に意図的なバックドアを導入し、安全に実装することが難しくなります。
しかし、これをより適切に管理する方法があります。例えば、監査ログは常に静止状態で暗号化されて保存されるべきであり、その監査ログにアクセスできるユーザーに対しては堅牢な保護が必要です。政府は簡単に監査できるオープンソースツールを使用し、監査ログがどのように保存され、どのサーバーに保存されるかについて非常に慎重に考えるべきです。
もし規制が更新されれば、分散型ソリューションが政府のコミュニケーションでより良く活用される方法を提供する可能性があります。
Q9. セキュリティを重視する組織に、Signal互換のプロプライエタリクライアントからSessionへの移行を促すには、どのように説得しますか？
TM SGNLのハッキングは、ユーザーがセキュリティとプライバシー機能が大幅に強化されたSessionのようなオープンソースツールに移行するための最も明確なインセンティブを提供していると思います。将来的には、組織がSessionのようなオープンソースツールを利用して、それらのツールに接続できる独自の監査ツールを開発することが可能かもしれません。しかし、そのような監査ソリューション自体もオープンソースであり、監査可能であるべきです。そうしないと、TM SGNLと同じ問題が再発することは避けられません。
Q10. 今後12〜18ヶ月の間に、Sessionのロードマップにはどのような主要な機能や改善が予定されていますか？最終的に、Sessionと安全でプライベートなメッセージング全体に対する長期的なビジョンは何ですか？
Sessionの現在の焦点は、より多くのユーザーにリーチすることです。Sessionはすでに月間アクティブユーザーが100万人を超えていますが、私たちは、アプリケーション設計の中心に強力なプライバシーとセキュリティを組み込んだソリューションを選ぶユーザーがさらに増えることを望んでいます。Sessionの貢献者たちは、Sessionのパワーユーザー向けのプレミアム機能のスイートに取り組んでおり、Sessionエコシステムへの持続可能な資金提供を可能にしています。これには、より大きなグループ、より多くのプロフィールのカスタマイズ機能、増加したファイルサイズなど、Sessionのユーティリティを高めるすべての機能が含まれています。
より広く言えば、私はSessionを、コンテンツとメタデータのプライバシーを非常に消費しやすく使いやすい体験の中で提供する唯一のアプリと見ています。そして、データ侵害がユーザーに影響を与え続ける中、Sessionは今後12～18ヶ月の間に成長し続けると思います。