電子メール、ICQ、Twitterのいずれであっても、最新のシステムでは、サーバーの所有者がこのすべてのデータを保持しており、必要に応じて公式または非公式のリクエストを受け取ったときに共有できます。 以下は、I2Pの上に構築されたネットワークのプロジェクトです。所有者は、通常のI2Pノードよりも多くの情報を持たない、より安定した動作を確保するためにノードを使用します。
I2Pの匿名性と機密性を確保するためのメカニズムを検討します。これは、ネットワークの構築に依存します。
- 各I2P参加者は、ネットワークの残りの部分に知られているルーターであり、「見えない」ネットワーク自体を形成する1つ以上のアドレスです。 I2Pの意味は、このアドレスまたはそのアドレスがどのルーターにあるかを知ることが実際上不可能であることです。
- I2Pアドレスは、非対称暗号化と署名用の公開キーペアです。 秘密鍵のペアは所有者によって保存され、アドレスの信頼性の確認です。 言い換えれば、認証の場合、パスワードの代わりに、キー付きのこのファイルが使用されます-必要に応じて、電子デジタル署名の類似物をトークンとして実装できます
- ルーター間の接続はAESを使用して暗号化されます。AESは、中間者攻撃に対抗するためにホストアドレスの署名を確認するなど、いくつかの手順でセッションキーがネゴシエートされます
以前 、I2Pは実際には2レベルの設計であることが示されました。他のルーターやトンネルとの相互作用を提供するルーターと、アプリケーション間でデータを転送するために設計されたプロトコルです。 ルーターのプロトコルが慎重に考えられて効果的であると思われる場合、アプリケーションプロトコルは、既存のアプリケーションに対して可能な限り汎用性と透過性を持たせたいという要望により、多くの要望が残され、さまざまな概念やアイデアの山になります。 私たちの場合、顧客間のやり取りを想定しているため、タスクは大幅に簡素化され、独自のプロトコルを使用できます。
別のI2Pの問題は、アドレスにアクセスしようとすると、「アドレスが見つかりません」というエラーが発生することです。ただし、指定されたアドレスのリソースは現在オンラインです。 これは、ネットワークデータベースの不完全性が原因で発生します。たとえば、開始直後に、多くのルーターに関する情報が古くなって更新に時間がかかる場合です。 また、アドレスはLeaseSetsを「最も近い」フラッドフィルに公開するため、クライアントはまだデータベースに必要なフラッドフィルがない場合があります。 クライアントは、サーバーに対応するノードのセットを含む2番目のネットワークデータベースを使用し、これらのノードでのみLeaseSetを公開します。これにより、互いのLeaseSetをすぐに見つけることができます。
各I2PノードはI2Pアドレスによって識別されます。I2Pアドレスは、ノードがランダムに作成されたときに生成された2組の公開鍵と秘密鍵であり、IPアドレスや場所とは関係ありません。 アドレスの中央ソースはありません。2つのランダムに生成されたアドレスが一致する確率は無視できると想定されています。 ノードの所有者は、キーの完全なセットを持つファイルを持っている所有者です。 2つの公開鍵と3バイトの証明書（現時点では常にゼロ）がノードの387バイトの識別子を形成し、それによってノードがI2Pで認識されるようになります。 完全な387バイトの識別子は、データの比較、ソート、および転送にはかなり非効率的であるため、識別子からの32バイトのSHA-256ハッシュを使用してノードを指定し、これを使用してクライアントを識別します。 アドレスには署名キーが含まれているため、攻撃者が別のクライアントになりすますことは困難です。これは、この識別子に対応するハッシュのようなキーペアを選択することと同じです。 必要に応じて、クライアントは自分のキーでドキュメントに署名することにより、I2Pアドレスの背後に隠れているのが自分であることを確認できます。
したがって、私たちのネットワークは、コンピューターとサーバー上のコンピューターで実行されているクライアントで構成されます。 クライアントとサーバーは両方とも本格的なI2Pルーターです。一方、サーバーは高速であると宣言されており、主にトランジットトラフィックの伝送用に設計されていますが、クライアントは主に独自のトンネルとトランジットトラフィックを使用してアクティビティをマスクします。 サーバーに関する情報は公開されており、クライアントに知られていますが、サーバーはクライアントについて何も知らず、クライアントを通常のI2Pノードと区別することはできません。 クライアントは、トンネルに1つのサーバーがあり、残りのノードが通常のI2Pの他の参加者に属するように、トンネルのノードを選択します。 すべてのサーバーが攻撃者の制御下にある場合でも、1つのノードではI2Pの標準3ステップトンネルのもう一方の端を決定するのに十分ではありません。 ユーザーは、疑わしいノードを除外するだけでなく、トンネルのルートを常に見る機会があります。
一方、トンネル内のサーバーの1つは、動作を停止したトンネルを早期に検出してトンネルの信頼性を高めるために必要です。 これはI2Pの基本的な問題の1つです：ノードがトランジットトンネルに参加することに同意してから動作を停止した場合（たとえば、ユーザーが停止した場合）、トンネルの作成者はこれについて何も知らず、長時間アイドルトンネルを使用し続けます。 通常のI2Pとは異なり、クライアントはテストメッセージをトンネルにアクティブに送信し、サーバーがトンネル内のトラフィックの不足を検出するとすぐに、クライアントに通知を発行し、クライアントがそのようなトンネルの使用をすぐに停止できるようにします。
顧客間でデータを交換するには、I2NPタイプ20-任意のデータを含むデータメッセージ、またはタイプ11-ニンニクメッセージを使用できます。 当初、I2Pでは次のアドレス間の交換スキームが想定されていました。宛先のLeaseSetが要求され、次に宛先としてアドレスを示すニンニクタイプのメッセージが生成され、LeaseSetの公開暗号化キーで暗号化され、適切なトンネルに送信されます。 このようなメッセージを受信すると、ルーターはそれを解読し、メッセージの宛先を決定しました。 ただし、この場合、暗号化キーはこのルーターにあるすべてのアドレスで同じである必要があり、大きなセキュリティホールが作成されたため、現代のI2P実装では、各アドレスはそれぞれ独自の着信トンネルと暗号化キーのセットを持ち、ルーターはアドレスを決定でき、 「ニンニク」メッセージなし。 「ニンニク」暗号化の使用を放棄することで、別のかさばるI2PデザインであるAES / ElGamalエンジンを取り除き、タイプ11のメッセージを送信してトラフィックを通常のI2Pと見分けがつかないようにする一方で、タスクにより効率的な暗号化を使用できます。
クライアントは、ネットワーク内の自分自身と外部の受信者の両方でメールを交換できます。 最初のケースでは、I2Pアドレスが直接使用され、メッセージはLeaseSetアドレスからトンネルを介して送信されます。 クライアントがこのアドレスのLeaseSetを見つけることができない場合、一定時間それを続け、その後、配信不可能に関するメッセージを生成します。
2番目の場合、クライアントは送信サーバーとしてサーバーの1つを使用する必要があります。 各サーバーには独自のアドレスがあり、クライアントのアドレスはサーバーによって割り当てられたユーザー名に対応し、有効なメールアドレスを形成します。 クライアントがネットワーク外に電子メールメッセージを送信する場合、LeaseSetサーバーを見つける必要があります（そして、確実にそれを見つけます）。その後、サーバーはメッセージをメールとして認識し、通常のSMTPサーバーとして宛先に送信します。 受信者は、SMTPサーバーのアドレスのみを知っているため、このアドレスまたはそのアドレスの背後に隠れている人を探したい場合でも、私たちが伝える最大値はI2Pアドレスであり、そのアドレスはまだ不明です。 サーバーが外部からメッセージを受信した場合、ユーザーは名前でそのI2Pアドレスを見つけ、ネットワーク内で通常の方法で送信します。
スパムに対抗するために、各I2Pアドレスから送信されるメッセージの数に制限を設けます。 アドレスが外部にメッセージを送信できるようにするには、サーバーに登録してその名前を確認する必要があります。同時に、リソースを大量に消費する計算タスクの結果として取得された証明書を必要とするため、アドレスの大量生成が複雑になりますが、必要なアドレスは1つ以上です。
したがって、一方では、送信された情報の匿名性と機密性を確保するネットワークを取得します。その情報の開示は、クライアントのコンピューターへのアクセスなしでは不可能であり、他方では、暗号識別ツールを使用してクライアント間の高いレベルの信頼を維持します 独自のプロトコルを使用し、それをクライアント間でのみ使用すると、実装が大幅に簡素化され、ネットワークの信頼性が向上します。新しい高速ルーターの登場により、I2P自体のパフォーマンスと帯域幅が向上します。
提案されたプロジェクト全体に関する尊敬されているHabrコミュニティの意見、そしてまずクライアントを匿名化する潜在的な攻撃、およびその他の弱点と脆弱性について意見を聞きたいと思います。