3

ほとんどの人が知っているように、電子メールは非常に安全ではありません。クライアントと電子メールを送信するサーバー間の SSL で保護された接続を使用しても、メッセージ自体はインターネット上のノードを飛び回る間はプレーンテキストであり、盗聴に対して脆弱なままです。

もう 1 つの考慮事項は、送信者は、メッセージが、たとえ意図された受信者であっても、ある程度の時間が経過した後、またはメッセージが一度読まれた後で、判読可能であることを望んでいない可能性があるということです。これにはいくつかの理由があります。たとえば、メッセージには、召喚状を通じて要求できる機密情報が含まれている場合があります。

解決策 (最も一般的な方法だと思います) は、メッセージを信頼できるサード パーティに送信し、そのメッセージへのリンクを受信者に送信して、受信者がサード パーティからこのメッセージを読み取ることです。または、送信者は暗号化されたメッセージ (対称暗号化を使用) を受信者に送信し、キーをサードパーティに送信できます。

いずれにせよ、このアプローチには根本的な問題があります。このサードパーティが侵害された場合、すべての努力が無駄になります。このような事件の実際の例については、Crypto AGが NSA と共謀したことに関する大失敗を参照してください。

私が見た別の解決策は、メッセージを暗号化し、鍵を断片に分割し、断片を DHT (つまり、Vuze DHT) に「保存」するVanishでした。これらの値は、ハッシュを検索するだけで簡単かつある程度確実にアクセスできます (ハッシュはメッセージと共に送信されます)。8 時間後、これらの値は失われ、意図した受信者でさえメッセージを読むことができなくなります。何百万ものノードがあるため、単一障害点はありません。しかし、これは DHT に Sybil 攻撃を仕掛けることによっても破られました (詳細については、Vanish の Web ページを参照してください)。

では、これを達成する方法についてアイデアを持っている人はいますか?

編集:私は自分自身を明確にしていないと思います。主な懸念事項は、受信者が意図的にメッセージを保持することではなく (これを制御することは不可能であることはわかっています)、メッセージがどこかで利用可能になることです。

たとえば、エンロンの大失敗では、裁判所はサーバー上のすべての電子メールについて彼らに召喚状を発行しました。メッセージが暗号化されていて、キーが永遠に失われていた場合、暗号化されたメッセージがあり、キーがないと、何の役にも立ちません。

4

8 に答える 8

1

ユーザーはスクリーンショットを撮り、暗号化されていないスクリーンショットをディスクに保存することができるため、自己破壊的な部分は本当に難しいです.外部ページ)。ただし、受信者に後で削除するように依頼することはできます。

一方、暗号化はまったく問題ではありません。送信者とクライアントがTLSを使用している場合でも、TLSを使用していない他のメールが依存し、メッセージをプレーンテキストとして保存する可能性があるため、私はTLSに依存しません。したがって、最善の方法は、明示的に単純に暗号化することです。

たとえば、私が書く (ほぼ) すべてのメールに GnuPG を使用していますが、これはいくつかの非対称暗号化方式に基づいています。ここでは、明示的に許可した人だけがメールを読むことができることを知っています。また、ほとんどすべての一般的な MUA で利用できるプラグインがあるため、受信者がメールを読むのも非常に簡単です。(そのため、誰もメールを手動で暗号化する必要がなく、暗号化されていないメッセージをディスクから削除するのを忘れる可能性があります...)。また、たとえば誰かが秘密鍵を盗んだ場合 (通常は暗号化されています)、鍵を取り消すこともできます。

私の意見では、GnuPG (または代わりに S/MIME) を常に使用する必要があります。しかし、それはおそらく私の愚かな夢の 1 つにすぎません ;)

于 2010-07-19T19:00:33.790 に答える
1

(免責事項: Vanish や Sybil の攻撃に関する詳細は読んでいません。以下の内容と似ている可能性があります)

まず第一に、電子メール メッセージは一般的に非常に小さいものです。50 MB の YouTube vid と比較すると、1 日に 10 回以上ダウンロードできます。これに基づいて、ストレージと帯域幅はここでは実際の問題ではないという仮定に基づいています。

暗号化という言葉の常識では、理解が困難で検証が困難な部分がシステムに導入されます。(誰もが実行する典型的な openssl マジックを考えてみてください。ただし、99% の人は本当に理解しています。HOWTO のステップ X が「サイト X に移動し、*.cer *.pem および *.csr をアップロードしてください」とステップを確認する場合) 1からX-1、10人に1人くらいはやると思う)

2 つの観察結果を組み合わせて、安全な (*) わかりやすいシステムを提案します。

10 kb のメッセージ M があるとします。おそらくハードウェアベースのランダムソースから N 倍の 10 kb を取得し/dev/(u)random、それを K(0) から K(N-1) と呼びます。単純な xor 演算を使用して計算します

K(N) = M^K(0)^K(1)^...^K(N-1)

今、定義上

M = K(0)^K(1)^...^K(N)

つまり、メッセージを理解するにはすべて K が必要です。任意のプロトコルを使用して、ランダムな 256 ビット名で、N の異なる (多かれ少なかれ信頼できる) パーティーで K を保存します。

メッセージを送信するには、N リンクを K に送信します。

メッセージを破棄するには、少なくとも 1 つの K が削除されていることを確認してください。
(*) 安全性に関しては、システムは最も安全なパーティが K.

ブルート フォース攻撃を難しくするために、メッセージごとに 1 つのノードで固定数の K を使用しないでください (つまり、同じノードに 1 つのメッセージの 0 ~ 10 K を配置する)。キーを格納しているすべてのノードにアクセスできます。

注意: もちろん、これには他のソリューションと同様に追加のソフトウェアが必要ですが、必要なプラグイン/ツールの複雑さは最小限です。

于 2010-07-17T17:31:08.663 に答える
1

さまざまな方法があり、それぞれに良い点と悪い点があります。シナリオに適した方法を選択する必要があります。それについての最善の方法は、あなたの「最も一般的な」解決策と同じだと思います。信頼できるサード パーティは、実際にはあなた自身である必要があります。あなたは、独自の認証を使用して独自の Web サイトを作成します。そうすれば、仮想キーを誰にも渡す必要はありません。

ユーザーが独自の証明書を持つ、電子メールを読み取ることができる独自のクライアント ソフトウェアを作成することにより、双方向の認証方法を使用できます。後悔するよりも、安全であることをお勧めします!

于 2010-07-19T21:07:50.567 に答える
0

ご使用の環境で許可されている場合は、トラステッドブート環境を使用して、トラステッドブートローダーがトラステッドカーネルのブートに使用されていることを確認できます。これにより、トラステッドメールクライアントがメールの受信に使用されていることを確認してから送信できます。リモート認証を参照してください。

責任を持って電子メールをタイムリーに削除するのは電子メールクライアントの責任です。おそらく、メモリ内のストアのみに依存し、ディスクにスワップできないメモリを要求します。

もちろん、プログラムでバグが発生する可能性がありますが、このメカニズムにより、電子メールを保存するための意図的な経路がないことが保証されます。

于 2010-07-19T11:51:26.130 に答える
0

あなたが説明したように、この問題は、Vanish が対処し、彼らの論文で詳細に議論されている問題に非常に近いように思えます。お気づきのように、彼らの最初の実装には弱点があることが判明しましたが、それは根本的な弱点ではなく実装の弱点であるように思われるため、おそらく修正可能です。

また、Vanish は明らかに攻撃対象であることも十分に知られています。つまり、Vanish の弱点が発見され、公表され、修正される可能性が高いということです。

したがって、おそらく最善の選択肢は、Vanish バージョン 2 を待つことです。セキュリティ ソフトウェアを使用する場合、自分で開発することはほとんど良い考えではなく、定評のある学術セキュリティ グループから何かを取得する方がはるかに安全です。

于 2010-07-19T21:37:04.350 に答える
0

IMO、状況に対する最も実用的なソリューションは、Pidgin IM クライアントを Off-the-Record (ログなし) と pidgin-encrypt (エンドツーエンドの非対称暗号化) と共に使用することです。メッセージはチャット ウィンドウが閉じられるとすぐに破棄されます。緊急時には、コンピューターのプラグを抜くだけでチャット ウィンドウを閉じることができます。

于 2012-04-11T14:59:15.107 に答える
0

HTML 形式が使用されている場合は、後で削除できるメッセージ参照アセットを持つことができます。メッセージが後日開かれた場合、ユーザーには壊れたリンクが表示されるはずです..

于 2010-07-13T18:32:20.113 に答える
0

メッセージが後で読めなくなる可能性があることを受信者が知っていて、そのメッセージに価値があると判断した場合、受信者はメッセージを保存することを意図しているため、保護を覆そうとします。

暗号化されていないメッセージ、つまり、テキストまたは画面イメージのいずれかの知覚可能な形式でメッセージを見た人は、何らかの方法でそれを保存し、好きなことを行うことができます。キーなどを使用したすべての対策は、メッセージの処理を不便にするだけですが、テキストの抽出を妨げるものではありません。

方法の 1 つは、Mission Impossible のように自己破壊ハードウェアを使用することです。ハードウェアはメッセージを表示してから破棄しますが、ご覧のとおり、これも不便です。受信者はメッセージを見てメッセージを理解する必要があります。常に可能であるとは限らない一度だけ。

したがって、受信者が保護を覆すことに関心がある可能性があり、保護が覆される可能性があるという事実を考えると、アイデア全体が意図したとおりに機能しない可能性がありますが、メッセージの処理が不便になることは間違いありません。

于 2010-06-30T06:14:54.700 に答える