Jami（以前のRing.cx）は実際にどのように機能し、どのくらい安全ですか？
Jami自分自身を呼び出す 「音声、ビデオ、チャットによるコミュニケーションのための究極のプライバシーとコントロール」。しかし、オンラインのフォーラムでは、暗号化プロトコルが不適切であり、ソースコードが乱雑であると（少し詳しく）触れています。そのアーキテクチャについて正確に何が安全ではなく、なぜこれらの側面の問題があるのですか？
音声やチャットの会話に完全な転送セキュリティを提供しているようには見えません。 ...彼らは、リアルタイム通信用に設計されたOTRやAxolotlなどのプロトコルを使用していません。 ...彼らの暗号化の説明は私の懸念を裏付けています。彼らはMITM攻撃を防ぐためにZRTPのようなプロトコルを使用していません。 （リンク）
... WhatsApp、Ring、ChatSecure、Signalなどの他のソフトウェアは、思ったより安全ではありません。 ...「リング」はSIPプロトコルを使用しています。これは非常に古く、P2Pフレンドリーではありません。彼らはそれを「分散型」ソフトウェアであると主張し、それは強み***です。 （リンク）
一方、Ringは、「確立された標準」を使用したいと考えているようです。これには、セキュリティを取り除く抜け穴がたくさんあります。
これは安全なプロトコルの現実を反映しておらず、実際のセキュリティ専門家は通常「DIYセキュリティ」を危険であると見なし、確立されたプリミティブまたはプロトコルにさえ依存しています。 （リンク）
こんにちは、リング開発者はこちら。リングは分散通信プラットフォームであり、そのノードはDHTネットワークの一部であるため、IPは実際に公開されています。 （リンク）
壊れていると考えられる暗号をサポートします。 https://en.wikipedia.org/wiki/POODLE また、彼らは暗号ライブラリにパッチを適用しています–使用している暗号ライブラリにパッチを適用する必要がある場合、深刻な問題が発生します。それはパッチ自体ではなく、「あなたの暗号ライブラリがどれほど壊れているので、あなたはそれをパッチしなければならないのですか？」 – ring-daemon @ 8ca874d790be92649187aabcb55fa998dae045dfもっと詳しく調べますが、見れば見るほど悪くなります。 Toxにはまったく匹敵しません。
（…）確立された暗号化ライブラリだけでなく、確立されたプロトコルにも基づいて構築することにより、Toxとは少し異なるアプローチを取ります。それが（表示されるように作られているので）それがセキュリティ面で健全でないようにするのに十分である場合...まあ、簡単に言えば、それは十分ではありません。
壊れたものの上に構築されていませんか？つまり、TLS/SSL。 ...これは複雑さの問題です。何かを処理するのが複雑になるほど、結果としてバグが多くなります。 TLS/SSLのような複雑なものを使用すると、バグのある暗号コードを作成するのに役立ちます。 IMO SSL/TLSを使用するものはすべて、遅かれ早かれ壊れるでしょう。 ToxがNaCl/libsodiumを使用する理由の1つ。 （リンク）
Jami（以前のリング）開発者として、私はこれに答えようとします。もちろん、この回答は必然的に偏って不完全ですが、Jamiの動作に関するいくつかの懸念や誤解に答え、そのアーキテクチャとこのアーキテクチャの限界を理解するのに役立つ可能性があります。
安全な分散型リアルタイム通信プラットフォームを構築することは、多くの場合、使いやすさ、パフォーマンス、プライバシーの間のトレードオフです。 Jamiのセキュリティモデルは完全ではなく、進化する可能性が高く、コメント、提案、および批判にオープンです。必要に応じて、この回答を編集して詳細を追加します。
音声やチャットの会話に完全な転送セキュリティを提供しているようには見えません。 ...彼らは、リアルタイム通信用に設計されたOTRやAxolotlなどのプロトコルを使用していません。 ...彼らの暗号化の説明は私の懸念を裏付けています。彼らはMITM攻撃を防ぐためにZRTPのようなプロトコルを使用していません。
Jamiは、認証されたピアツーピアTLS 1.3セッション（GnuTLSを使用）を確立し、通常は（TLS1.3）-（ECDHE-SECP384R1）-（RSA-PSS-RSAE-SHA384）-（AES-256- GCM）が使用されます。
このP2P認証済みTLSチャネルはSIPシグナリングに使用され、一時的なSRTPメディア暗号化キーはこのチャネルでSIPとネゴシエートされます。これは、リアルタイム通信がJami（オーディオとビデオ）はPFSでエンドツーエンドで暗号化されていますが、Jamiは否認などの他の保証を提供していません。
「クラシック」（サーバーベース）SIPでは、SIPでのメディアキーのネゴシエーションは問題です。SIPサーバーはこれらのキーをプレーンテキストで表示できるため、エンドツーエンドの暗号化とMITM攻撃の許可。これは、ZRTPがRTP（media）チャネルでDHキー交換を実行することにより解決します。SIP on認証されたP2Pチャネルにより、ZRTPの使用が不要になります。
「リング」はSIPプロトコルを使用しています。これは非常に古く、P2Pフレンドリーではありません。
SIPプロトコルは、P2P通信にHTTPを使用できるのと同じように、P2Pにうまく使用できます。これは、完全ではなく、一部の人々であっても、確立された堅牢なテレフォニープロトコルです。 XMPPまたはその他を優先します。
彼らはそれを「分散型」ソフトウェアであると主張し、それは強みである***。
Jamiは完全に分散されています 分散型より強力 、OpenDHT（Bittorrentで使用されるものと同様のKademlia分散ハッシュテーブル）を使用してDHTに保存されている連絡先IPアドレスを検索します。暗号化 [〜＃〜] ice [〜＃〜] 候補、認証済みTLS P2Pチャネルを確立するために使用されます。ユーザー名（name <->公開キーマッピング）は、分散ブロックチェーン（Ethereumコントラクト）に登録されます。私の知る限り、このレベルの配信を提供する他のリアルタイム通信システムは他にありません。
リング開発者はこちら。リングは分散通信プラットフォームであり、そのノードはDHTネットワークの一部であるため、IPは実際に公開されています。
これは、分散ネットワークを使用することの欠点です。DHTノードのIPアドレスが分散ネットワーク上で公開されます。これは、有効なプライバシーの問題です。現在の設計では、DHTノードをJami公開鍵に暗号化してリンクすることはできません。この分離をできるだけ強くするように取り組んでいます。
また、彼らは暗号ライブラリにパッチを適用しています。使用している暗号ライブラリにパッチを適用する必要がある場合、深刻な問題が発生します。
壊れたものの上に構築されていませんか？つまり、TLS/SSL。 ...これは複雑さの問題です。何かを処理するのが複雑になるほど、結果としてバグが多くなります。 TLS/SSLのような複雑なものを使用すると、バグのある暗号コードを作成するのに役立ちます。 IMO SSL/TLSを使用するものはすべて、遅かれ早かれ壊れるでしょう。 ToxがNaCl/libsodiumを使用する理由の1つ。
（Tox開発者による上記のコメント）
「暗号化libにパッチを当てる」ことはありません。バグや脆弱性が見つかると、ライブラリが更新されます。
私たちは、暗号ライブラリ（および一般的にライブラリ）が完璧ではない現実の世界に住んでいます。時間が経つにつれて、すべての暗号が壊れてしまいます-それは予測ではなく観察です。
TLSの複雑さは欠点ですが、利点は暗号スイートをネゴシエートできることです。そのため、暗号スイートが弱いと見なされ始めると、既存の実装を壊すことなく、新しい暗号スイートへの移行を適切に行うことができます。
Libsodium（NaCL）は優れた高品質のライブラリですが、TLSと直接比較することはできません。 NaCLは基本的な暗号化ビルディングブロックを提供しますが、TLSは、認証、鍵交換、暗号化などのすべてを標準的かつ十分に検討された方法で実行するプロトコルです。
Jamiを構築するとき、脆弱性を追加するリスクを回避するために、できる限りホイールを再発明しないようにしました。 libsodiumを使用して独自のプロトコルを構築する代わりに、TLSに依存することを好み、それを可能な限り最良の方法で使用することに焦点を当てました。
aberaud 言った：
リングは、認証されたピアツーピアDTLS 1.2セッションを（GnuTLSを使用して）確立し、PFS暗号スイートを適用します。通常、TLS_ECDHE_RSA_AES_256_GCM_SHA384が使用されます。
このP2P認証済みTLSチャネルはSIPシグナリングに使用され、一時的なSRTPメディア暗号化キーはこのチャネルでSIPとネゴシエートされます。これは、リアルタイム通信がon Ring（オーディオとビデオ）はPFSでエンドツーエンドで暗号化されていますが、Ringは否認防止のような他の保証を提供していません。
「リング上の通信（オーディオとビデオ）はPFSです」という部分は、あなたがPFSと言うことに応じて当てはまります。会話から次の会話へ、つまり2つの後続の接続確立（鍵交換）の間で、通信は実際に完全な前方安全かつ後方安全です。ただし、複数のメッセージが交換される同じ会話中に、後続の各メッセージは同じ鍵を使用して暗号化されます。
そのため、同じ会話内のメッセージは、PFSで交換されず、逆方向の安全な方法でも交換されません。
同じ会話中にOFSなどのPFSとBS通信を実現するには、実際にAxolotlを使用する必要がありますが、これはオーディオ/ビデオに直接最適ではなく、テキストメッセージに適しています。質問をオーディオ/ビデオ暗号化に制限する場合、SCIMP（Axolotlからのラチェットの1つ）を使用して、同じ会話中に通信PFS（ただしBSではない）を作成できます。グループ内のメッセージの交換に関して、リングは [〜＃〜] gotr [〜＃〜] 、 mpOTR 、または1対1のAxolotlのようなものを使用する必要があります全員間の安全なチャネル。ただし、Axolotlはグループの懸念事項を単独で管理することはなく、GOTRはmpOTRを上回るように設計されています。したがって、GOTRが最適です。リング開発者チームが実際に年の初めからそれらの状況を調査していることは言及する価値があります。
Ring.cxが特に安全ではない（実際にはほとんど正しく機能しない）理由をもう少し説明します。
セキュリティの大部分は、攻撃ベクトルと、システムへの侵入を減らすことです。あなたは常に何かを信頼しなければならず、それに対する信頼が誤っている可能性があるため（おそらく、接続している他のユーザーがスピーカーから他の誰かにあなたが言うすべてを転送するなど）、それをゼロに減らすことは決してありませんが、アイデア安全とは、あなたのベクトルは小さくて少数であり、大規模で多くであると言うことであり、あなたが知っているもの（そしておそらくあなたが知らないもの）に対して特定の対策を準備できるようにすることです。
厄介なソースコードが問題であると人々が言っている理由は2つあります。
- 秩序が欠けている場合、バグを隠すことは非常に簡単であり、バグは潜在的な悪用の可能性があります。もちろん、見栄えのよいプログラムであっても、完全にバグがないことはありませんが（数学的なセキュリティ監査によって何らかの方法で証明されない限り）、乱雑なプログラムには、非常に多くのバグ、nullポインタなどが含まれている可能性があります。
- チームはまだプログラムクライアントを正しく機能させるのに苦労しており、プログラムは依然として定期的にクラッシュし、エラーが発生し、機能が不足しています。
- ソースコードをざっと見ると、どのクライアントもテストされていません。
- ほとんどのコードはC Plus Plusで記述されています。この言語を保護できないというわけではありませんが、これはスタックオーバーフロー、ポインターエラー、メモリオーバーフローなどで悪名高い言語です。RustまたはGoでさえ、これらの種類の問題に対するより基本的な保護を提供します。
- コードのスタイルはクライアントプロジェクト間で大幅に異なります。スタイルが異なることはできないと言っているわけではありませんが、これは、スキルとコーディング基準が異なる非常に異なる開発者が貢献していること、そして「いいえ、このコードは私たちの要件を満たしていません標準 '
- ビルドシステムは非常に複雑で、潜在的な問題がたくさんあります。あなたはどちらか一方のビルドシステムについて特別な感覚を持っているかもしれませんが、これは最大5または6-python、cmake、autotools、bash、g ++、VC++を利用しています。つまり、ビルド自体に違法な依存関係を挿入する方が簡単であり、純粋に数字だけでプロジェクトを汚染する可能性が高くなります。
- それ自体が疑わしい品質である可能性がある多数の外部依存関係を引き込みます。これは理にかなっていますが、たとえば、独自のライブラリを開発およびテストしていないためです。ビデオのデコード/エンコード、それらの品質とセキュリティは、サードパーティのライブラリと同じくらい良いです。過去のLinuxセキュリティの脆弱性の多くは、他の方法では安全なシステムを安全でないPOC（Pile Of Crap）に変えてしまう悪用可能なバグを持つ不明瞭な機能を持つ不明瞭なライブラリーと関係がありました。
- 明確な指示や指示のない断片化された開発
- クライアントは1つのクライアントではなく、6つです。2つのWindowsクライアント、2つのモバイルクライアント、1つのLinuxクライアント（2つある場合もありますが、サイトにはgnomeとkde linuxクライアントがあると混乱しています）、および1つのElectron/Webがあります。クライアント。これらのクライアント間には共通のコードはなく（ring-lrcとring-daemonは無視）、チームはこれが特定のプラットフォームに制約を課さないためのより良い「設計」であると主張しますが、それは彼らが優れたセキュリティを保証できないことを意味します彼らが3つのクライアントをサポートしているかのように彼らのプラットフォーム、例えばAndroid、IOS、デスクトップ。
- 彼らは、コード内で複数の非相補的なライブラリを利用しています。同じLinuxアプリケーション内で、GTK + QTを使用しています。どちらも同じ機能を提供し、サポートされている互換性のない独立したツールキットです。これは潜在的なバグの主な原因です。 AndroidとIOSの間の基本的な非互換性については、行うべきことは多くありません。1つのハードウェアモバイルプラットフォームのみがより安全であると主張することができます-もちろん、適切に設計されている場合）Windowsクライアントは、QT + GTKアプリケーションの一部であり、ユニバーサルWindowsプラットフォームクライアントです。
- この記事の執筆時点では、プロジェクトの構築方法を説明するwikiページのみがあります。クライアントがクライアントライブラリやデーモンとどのように通信するか、またはバグを修正するか、新しい機能を実装する方法の基本的な一般的なアーキテクチャでさえ、方向性はありません。これは、新しい開発者が何かを実装する方法について賢明な決定を行うだけでなく、最終的に安全な決定となる決定を行うことは非常に難しいことを意味します。
ネットワーキング/セキュリティ実装アルゴリズムの観点からすると、それらが使用しているライブラリの一部は、確かに安全でないか、古くなっているか、単に壊れている可能性があります。上記は、クライアントのUIレイヤーよりもハードな作業、ネットワークセキュリティレベルの作業が優れていないこと、そしておそらく事態が悪化していることをかなり説得力のあるライブラリにする必要があります。
DHTやダブルラチェットアルゴリズムなどの一部のアイデアは、安全なセキュリティのアイデアであり、安全なプリミティブを利用できる場合もありますが、このため、このアプリケーションの安全性は最低限考慮しません。クライアントが正しいことをしていると数えることができない場合、それはデスクトップ上の特権のないユーザープロセスによってハイジャックされないということであり、ネットワーキングライブラリによって行われた有効なセキュリティ保証は失われますか？または、古い安全でないネットワークライブラリを使用している場合、一部の機能を有効にして安全なアルゴリズムの使用を無効にする方法がないということですか。
これらすべてが言われていますが、セキュリティアルゴリズムに一種の「研究」プロジェクトとして焦点を当てて、多くのプラットフォームでマルチメディアを探索したい場合は興味深いプロジェクトですが、安全に実装されていますか？ほぼ確実にそうではありません。
この質問に答えるのは簡単ではありません。このサービスのためではなく、一般的な確認として。
このようなサービスは、適切な方法で暗号化を使用および実装することにより、可能な限り安全にすることができます。しかし、これにはいくつかのものが含まれます。
- よく知られた「安全な」暗号化システムの使用
- 適切に監査されたライブラリとシステムの使用
- 監査、パッチ適用、更新をすべて維持します
- そして最後に、適切に実装し、コード化し、それらすべてのパーツを一緒にデプロイします
しかし、最も重要なことは、この構造を安全に維持することです毎日。
これらのいずれかの点で失敗すると、サービスのセキュリティステータスが低下します。
たぶん明日、使用されているライブラリの1つに実装の欠陥が発見され、それを防ぐことはほとんど不可能です。
いくつかの技術的事実に基づいてサービスをセキュアまたは非セキュアとしてマークするようなアサーションを作成することは現実的ではありません。セキュリティは全体です:)