電子メールのさまざまな部分と共に、送信元と宛先のIPアドレスを暗号化するにはどうすればよいですか？
主題があなたにとって意味をなさない場合、それは問題ありませんが、私にとっては意味がありません。
一部のデバイスから送信された電子メールをセキュリティで保護する必要があり、いくつかの要件を明確にするために尋ねるインテリジェントな質問に関するアドバイスを探しています。どうやら、送信元と宛先のIPアドレスは、ログインに使用したユーザー名と電子メールメッセージ自体とともに暗号化する必要があります。
会話の送信元と宛先のIPアドレスを暗号化するには、IPSecなどを使用する必要があるようですが、正しいですか。そしてそれは、メールの送信時にアプリケーションの一部としてだけでなく、OSレベルで行われますよね？
ユーザー名を暗号化するために、それが何を意味するのかわかりません。ログインしようとするときに資格情報を暗号化すると、サーバーが何らかの方法で資格情報を復号化できない限り、ログインできなくなります。
電子メール自体を暗号化するために、PGPなどを使用する場合、電子メールを送信するデバイスと受信者のマシンにキーを設定する必要がありますよね？
私は要件についていくつかの調査を行いましたが、上記は私が思いついたものです。インテリジェントな質問を探して、上記の私の仮定を検証します。
ありがとう、
マーク
パケットの宛先を保護するには、ネットワーク層を完全に抽象化する必要があります。これは通常、何らかの形の暗号化されたVPNを意味します。これは、ローカルネットワーク上のハードウェアが、どのパケットがどこに送信され、何が含まれているのかを認識できないことを意味します。
残念ながら、これは実際の問題を解決するのではなく、上流に移動するだけです。 VPN /暗号化リンクはある時点で実際のネットワークに接続する必要があり、接続するとすぐに、正しいルーティング情報を使用する必要があります。あなたは時々IPブロックを移動することによってこれを軽減することができます/ネットへの複数の接続を持っていますが、これは維持するのが複雑になる可能性があります。
改善されたアプローチは、ネットワークからのルーティングをマスクするために [〜＃〜] tor [〜＃〜] を使用することです。 完璧ではない ですが、これは防御のもう1つのレイヤーです。
したがって、暗号化されたVPNを介したメールサーバーへのSSL SMTP接続と、TORを介した暗号化された電子メールが受信者のメールサーバーに送信される可能性があります。 （VPN上の他のマシンから保護するために、VPN暗号化の上にSSLを配置します。電子メールのソースを保証するために、クライアント証明書を検討することをお勧めします）
編集：コメントでユースケースを見つけ、smtpサーバーへの接続を保護することにのみ焦点を当てたので、どれほど簡単かによって異なりますセンサーを独自に構成することです。
安価な場合は、各センサーで一意のSSLクライアント証明書を使用します。これにより、接続が保護され、双方のIDが確認されます-偽装されたセンサーはありません。
構成にコストがかかる場合は、PSKベースの何かを使用します-暗号化は引き続き可能ですが、1つのデバイスが侵害された場合、それらはすべて[少なくともVPN内の誰にとっても]です。
ソースIP-管理するメールサーバーに接続する場合は、偽のソースヘッダーを書き込むように構成できます（送信側マシンにプライベートネットワークIP範囲を使用している可能性があるため、本当に重要ですか？）-ただし、上流のメールサーバー直接のメールサーバーの実際のIPアドレスが表示されます。書き込むヘッダーにその情報を忠実にコミットするかどうかは、別の問題です。
宛先IP-ある時点で、メールが適切にルーティングされるように、メールが通過するMTAに平文で表示される必要があります。その時点で、その電子メールを処理するMTAは、おそらく（必要に応じて）その情報をメールヘッダーに書き込みます。
ユーザー名を暗号化する-これはログインプロセスを保護することを意味すると思いますか？安全なトンネルを通過します。
電子メール自体の暗号化-送信者と受信者の電子メールクライアント、およびどれほどのユーザビリティが必要かによって異なります。 Truecrypted blobを添付ファイルとして送受信するだけで、メールクライアントを変更する必要はありません。または、あなたが述べたように、証明書ベースのシステムをデプロイします。詳細なデプロイメントの詳細は、電子メールクライアント、OS、および必要な互換性に大きく依存します（「部外者」が安全な電子メールを送受信する必要がある場合はどうなりますか？）。
2人の高度な技術者が、要件を満たしてメールを交換することは簡単ではありません。組み込みデバイスとそれらを管理している人々との間の通信についてそれを達成することは、気が遠くなるほどです。コンテンツの暗号化は最も簡単な要件です。 OPはGnuPGを使用し、各デバイスに一意の秘密鍵を与えることができます。あるいは、基本が示唆するように、OPはOpenSSLを使用して、それぞれに一意のクライアントキーを与えることができます。
ログインユーザー名がメッセージの一部である限り、個別に暗号化する必要はありません。メッセージの復号化後にユーザー名を隠しておく必要がある場合は、各ユーザーが匿名または仮名のアカウントIDを持つ可能性があります。
OPや他の人が観察しているように、ソースIPと宛先IPの暗号化は意味がありません。介在するネットワーク上の偶然の監視者からこれらのIPを隠すだけでよい場合は、両端でプロキシを使用するだけで十分です。しかし、デバイスマネージャーがデバイスのパブリックIPを認識してはならず、デバイスがデバイスマネージャーのパブリックIPを認識してはならない場合、かなりの課題があります。
一部の（多くの）はこれを笑うかもしれませんが、その場合はMixmasterリメーラーnymsを使用するのが最も簡単な方法です。各デバイスとマネージャーは、パブリックまたはプライベートのMixmaster nymserverに電子メールアドレスを持っています。追加の匿名性のために、一部のnymserverはTor非表示サービスとしてアクセスできます。送信暗号化メッセージは、宛先アドレスに到達する際に使用されるMixmasterリメーラーのチェーンを指定します。暗号化された返信はalt.anonymous.messagesに送信され、受信者が自分宛てのメッセージを識別できるように署名されます。クライアントは定期的に、オプションでTorを介してalt.anonymous.messagesのすべてのメッセージをダウンロードし、復号化できるメッセージを識別します。
これは、「送信元と宛先のIPアドレス」の意味によって異なります。
SMTPに基づく通常のインターネット電子メールは、メッセージが1つの "Mail Transfer Agent"（MTA）から別のものに移動するときに、IPアドレスのリストをメッセージのヘッダーに記録します。あなたはおそらくこれらを「メールサーバー」と考えるでしょう。 1つのメッセージが送信と受信の間で複数のMTAを通過することは珍しくありません。
ユーザーがメッセージの入力に使用したデバイスのIPアドレスを保護する場合は、比較的簡単です。代わりにメールを受け入れ、ヘッダーにメールユーザーエージェント（MUA）のIPアドレスを記録しないMTA（メールサーバー）が必要です。このMTAは、インターネットに適切に接続され、他のMTAからのメッセージを引き続き受け入れるために十分に信頼されている必要があります。アンチスパム戦争のこの時代では、これは少しトリッキーになるかもしれません。別のアプローチは、MTA自体のIPアドレスをMUAアドレスとして記録することです。
MUAがSMTP以外のプロトコル（通常はIMAPまたはPOP）を介してメッセージにアクセスするため、通常、最終受信者のMUAのアドレスはヘッダーに記録されません。アドレスのチェーンの記録は実際にはMTAアクティビティであるため、MUAは通常これを行いません。使用しているPOPサーバーまたはIMAPサーバーはそうかもしれませんが、一般的ではありません。
インターネットのSMTP電子メールインフラストラクチャを使用する場合は、関係するMTAがメッセージヘッダーでマークされます。