web-dev-qa-db-ja.com

SMIMEメールとPGPメールのセキュリティの違いは何ですか？

キー配布以外で、暗号化された電子メールデータ（メッセージ本文）に関連する技術的な詳細に固有の [〜＃〜] smime [〜＃〜] とPGPの違いは何ですか？

比較例

  1. セキュリティの比較：各形式のセキュリティ保証は何ですか？署名/暗号化キーの比較で十分ですか、それとも公開鍵のみに基づいて知覚されるセキュリティを低下させる可能性があるMUAに固有の実装および構成の詳細がありますか？

  2. 未署名のデータをどちらの形式にも追加できますか？ （例：免責事項）

  3. MTAは他にどのような変更を加えることができますか？可能なこと、不可能なこと、MUAに依存するものは何ですか？

  4. プライバシーと変更の例：どちらの形式もヘッダーを無視しますか？件名？

  5. 変更例：署名されたデータと署名されていないデータを同じメッセージに表示できますか？例えば秘密鍵がないかサポートがないために暗号化されたSMIMEおよびPGPをレンダリングしないMUAに「ヘルプメッセージ」が表示されますか？ （たとえば、HTMLメッセージには、最初のNバイトのみをダウンロードするテキストリーダー用の平文オプションがあります。同様のものを希望します）

  6. プライバシーの例の比較：RFC2822は、TOとCCの受信者を、キーを持たない人から隠していますか？ （例外、エンベロープには暗号化はありません、私はそれを理解しています）

  7. セキュリティの例の比較：整合性チェックは、キー配布チャネルにアクセスせずに中間MTAで実行できますか？

  8. プライバシーの例の比較：50Mbの添付ファイルを想定しています。両方のメッセージ形式は同じサイズですか？

  9. 監査の例：どちらもサードパーティの監査を可能にするゲートウェイの復号化/暗号化をサポートしていますか？

この質問が広すぎる場合は、この質問を制約する方法の具体例を提供してください。例えばメールのSMIMEとPGPの____の違いは何ですか？

encryptionemailprivacypgpsmime
6
goodguys_activate

1：PGPに対するS/MIMEの利点は、テキストではなく完全なMIMEエンティティに署名/暗号化することです。これにより、メッセージ全体/ rfc822に署名/暗号化できます。はい、ヘッダーはMTAに対して表示および変更可能である必要がありますが、これは、メール全体、S/MIME署名または暗号化を取得し、署名/暗号化されたS/MIMEエンティティを新しいメールコンテナーにパッケージ化することで実現できます。これは、内部の（暗号化された）サブジェクトを「クレジットカード番号1234-1234-1234-1234のクレジットレポートです」とし、外部のサブジェクトを「Aからの暗号化メールあなたの銀行！」.

ほとんどのMUAは、ボタン、添付ファイル、または「含まれている」メッセージを開く別のUI要素を表示することにより、message/rfc822コンテナに反応するか、ブラウザでの「iframes」のように、含まれているメッセージを元のメッセージ内に表示します。これらの両方を使用すると、RFCに従って非表示にする必要があるデータを除いて、すべての署名済みフィールドとすべてのデータを検証できます。これにより、暗号化されたメールに異なるを使用することも可能になります。

たとえば、外側のコンテナにはFrom: YourBank Info Department <[email protected]>ですが、内部の暗号化されたコンテナにはFrom: Name Namesson <[email protected]>

ただし、プレーンテキストだけでなく、完全なMIMEコンテナ/エンティティに署名/暗号化/復号化/検証する危険性がある1つのケースがあります。これは、誰かが作成または作成していないコンテンツに署名または暗号化する場合です。

たとえば、Imが男性であることを証明する公証人の例です（私はそれが「愚かな」例であることを知っていますが、MIMEエンティティに署名することの危険性を理解しています）。

公証人に次の署名をお願いするとします。

Content-Type: multipart/alternative; boundary="1234";

--1234
Content-Type: text/plain

Im a male
--1234
Content-Type: text/html

Im a female
--1234--

署名がS/MIMEで行われた場合、公証人は自分が表示するコンテンツを確認し、公証人のクライアントがHTMLメールを表示できないと言ってから、text/plainバージョンを表示します。公証人のサインは、公証人が男性を知っているためです。次に、署名されたメールを、HTMLメールクライアントを備えた検証者に転送します。これには、もちろん「Im a female」と表示されます。

別の例は次のとおりです。

 Content-Type: text/html

 I authorize the transfer of $ 100<font color="#FFFFFF"> 000 000 000</font><br>
 from your account to my account 1234 1234 1234

あなたがアカウントマネージャーとしてこれに署名するとどうなるかを適切に理解でき、ターゲットのメールクライアントは、銀行の従業員のメールクライアントが署名を検証した後、メールからHTMLを削除するとします。

この場合、PGPでは、署名、暗号化、復号化、または検証の対象が正確にわかるため、S/MIMEよりもPGPのセキュリティが大幅に向上します。

2：PGPでは、署名されていないデータを----- BEGIN PGP ...-----および----- END PGP ...-----の外に追加するのと同じくらい簡単です。 S/MIMEでは、これはS/MIMEコンテナーの外で行われます。これは、1と同様に行うことができます。署名されたメール全体を新しいmessage/rfc822コンテナに再パッケージ化し、免責事項を外部コンテナに追加します。ただし、S/MIMEメールに免責事項を追加する必要がある場合は、メールに署名する前に免責事項を追加できるCiphermailなどのゲートウェイ署名ソリューションを使用することをお勧めします。

3：MTAは、PGPおよびS/MIMEメールの両方のすべての外部ヘッダーを変更できます。とにかく、MTAは内部ヘッダーに触れるべきではありません（メールの署名、暗号化、復号化、または検証を除く）。一部のMTAは、受信サーバーが8BITMIMEのサポートを発表しない場合に、コンテンツを8bitmimeからqpに再コード化する場合があります。これは、署名付きメールを常にquoted-printableとして送信するのが最善の理由です。

4：S/MIMEは、これらのヘッダーをS/MIMEコンテナー内に移動することにより、Content-Typeなどのコンテンツの解釈に影響を与えるすべてのヘッダーに署名します。 PGPはコンテナーを完全に無視し、常にプレーンテキストに署名する必要がありますが、MUAはPGPアーマー内のコンテンツをフォーマット付きで表示する必要がある場合があります。場合によっては、これは署名の検証にも影響を与える可能性があります。たとえば、メールクライアントが可視コンテンツ（たとえば、HTMLタグが削除されている）をPGPベリファイアに送信すると、コンテンツは無効として出力されます。これの最良の方法は、PGPを使用する場合です。常に、PGPメールをコピーして貼り付ける外部ソリューションを使用してください。または、PGPメールをテキスト/プレーンとして再コード化できる中央ソリューションを使用して、コンテンツの解釈に影響がないことを確認します。

5：S/MIMEとPGPの両方で、クライアントがS/MIMEまたはPGPをサポートしていない場合でも、署名されたデータはエンドユーザーに表示されます。 S/MIMEでは、署名されたメールにはS/MIME非対応クライアントのsmime.p7sが添付されているように見えますが、メールを確認したくない場合は無視しても問題ありません。 PGPの場合、次のようになります。

-----BEGIN PGP SIGNED MESSAGE-----
bla bla bla

Best regards, Name Namesson
-----BEGIN PGP SIGNATURE-----
fkjhdklghdflhilgnegdngnlbvilgbdgeetbugbzjbeu
-----END PGP SIGNATURE-----

したがって、クライアントが署名をまったくサポートしていない場合でも、メールクライアントユーザーはメッセージの内容を見ることができます。検証手順を追加したい場合は、簡単にtihs [〜＃〜] inside [〜＃〜]署名されたメールを追加できます（署名されるため）。

署名されたコンテンツの外にそのような指示を追加したい場合は、私の回答のポイント2を参照できます。暗号化メールの場合、PGPでは署名付きメールの場合と同じです。たとえば、BEGIN/ENDヘッダー行の外側に追加します。 S/MIMEの場合、メールを再パッケージ化する必要があるため、暗号化されたメールは、message/rfc822コンテナー内に配置され、次に、復号化指示を含むプレーンテキストコンテナーに追加されます。

6：はい、暗号化されたメッセージ/ rfc822コンテナー内でこれらを移動するだけで、S/MIMEでToとCCを非表示にできます。ただし、スパムフィルターがTo：をエンベロープ受信者と比較する可能性があるため、スパムフィルターによってメールが破棄されるのを防ぐために、元の受信者を宛先とするToを設定することをお勧めします。スパム。ただし、CCを安全に非表示にして、キーを持っている人だけに表示することができます。

PGPではプレーンテキストを暗号化するため、PGPでは不可能です。ただし、プレーンテキストメールの冒頭に、「このメールのコピーを[email protected]と[email protected]に送信しました」などのテキストを手動で追加することもできます。

7：はい。中間MTAはメール内の署名を検証できます。 S/MIMEの場合、これは完全に透過的に行われます。 PGPでは、これは、中間MTAが認識し、そこからキーをダウンロードするキーサーバーにキーがアップロードされた場合にのみ発生します。 MTAからMTAへの整合性のために、代わりにDKIM、STARTTLS、およびSPFを使用することをお勧めします。例として、TLSをサポートしていることがわかっているメールサーバーにSTARTTLSを強制するようにMTAを構成できます。

8：いいえ。署名および暗号化されたメッセージは常に少しずつ大きくなります。これは、サイズ制限を課すホストへのメールに署名または暗号化する場合に考慮する必要があるものです。同様に、S/MIMEとPGPはメールを可能な限り小さくするため、暗号化されたメールは実際にはメッセージのサイズを大まかに「リーク」します。ただし、不要なデータを埋め込むことにより、暗号化されたメッセージの「真の」サイズを隠すことができます。 「これは、暗号化されたデータが常に同じサイズになるようにするためのパディングです」のような通知を追加することもできます。そして、大きなブロックのlorem ipsumテキストを追加します。 lorem ipsumブロックのサイズは最大のメールより小さくてはいけないことに注意してください。そうしないと、暗号化されたコンテンツで、特定のサイズより大きいメールを見ることができます。

S/MIMEはすべてのテキストに大きなブロックで一度に署名または暗号化してから、smime.p7s添付ファイルを追加することに注意してください。暗号化されたS/MIMEメールには添付ファイルsmime.p7mのみが含まれ、PGPは添付ファイルを個別に暗号化するため、サイズがリークします。 PGP添付ファイルは全体が暗号化されます。 PGP添付ファイルは、署名を含むメールに新しい添付ファイルを追加することによって署名されます。たとえば、PowerPoint.pptは、添付ファイルPowerPoint.ppt.ascをメールに追加することによって署名されるため、メールにはPowerPoint.pptとPowerPoint.ppt.ascファイルの両方が含まれます。ただし、暗号化時に添付ファイルのサイズを非表示にしたい場合は、添付ファイルを常に.Zipファイルに入れてから、このZip内に、すべてのZipを固定サイズにする大きなファイルなどの不要なファイルを置くことができます。次に、圧縮に基づいて不要なファイルのサイズを計算する（または圧縮をオフにする）必要があり、不要なファイルはランダムなデータである必要があることに注意してください。添付ファイルと不要なファイルを含むこのZipを暗号化すると、1つのバイナリブロブに変換されます。キーを持たないものは、送信した添付ファイルのサイズ、名前、または数について何も見ることができません。

9：はい。ただし、ゲートウェイが受信者の秘密鍵を知っている場合に限ります。これは、PGPとS/MIMEの両方に有効です。秘密鍵がわからない受信者への監査メールをゲートウェイ処理する場合は、ゲートウェイからのメールを常に暗号化して、「暗号化されていない」メールをゲートウェイに送信できますが、STARTTLSなどの他の方法で暗号化できます。または、ゲートウェイが秘密鍵を知っている鍵で暗号化されたPGP/SMIME。サードパーティがサイト外にある場合は、常にサードパーティのキーをS/MIMEとPGPの両方の受信者として追加して、監査者が実際の受信者に加えて復号化できるようにすることができます。

4
sebastian nielsen