6

重要なのは、ユーザーが（サーバーからのサポートを受けて）暗号化されたメッセージをユーザー間で送信できるシンプルなシステムを設計することです。

このシナリオでは、クライアントにローカルストレージがないため、ユーザーが必要に応じて選択、記憶、入力できるパスワードを使用する必要があります。（これはシステム全体を弱めることを私は知っていますが、これは難しい要件です）

もう1つの要件は、サーバーがクリアテキストの秘密鍵やメッセージの復号化に使用できるその他のデータを保存できないことです（たとえば、ユーザーのみが暗号化されたメッセージを読み取ることができ、サーバー管理者は読み取ることができないはずです）。

私のアプローチは、クライアントで非対称キーペアを生成し、秘密キーの暗号化されたコピー（ユーザーパスワードで暗号化された）とともにサーバーで公開キーを公開することです。その後、ユーザーは、受信者が公開した公開鍵を使用して、暗号化されたメッセージを他のユーザーに送信できます。ユーザーがメッセージを復号化する必要がある場合、ユーザーの（暗号化された）秘密鍵がサーバーからクライアントにフェッチされ、ユーザーが提供したパスワードで復号化されてから、メッセージの復号化に使用されます。

これは意味がありますか？このシステム設計に欠陥はありますか？（ユーザーが短いパスワードまたは不正なパスワードを選択することに起因する弱点は別として）このアプローチは、同様のシナリオですでに使用されていますか？

ありがとうございました ：）

4

4 に答える 4

2

私が正しく理解していれば、2人のユーザーが信頼できないサーバーを介してプライベート通信を開始できるシステムを作成したいと考えています。

これは機能しません。

レイアウトするシナリオでは、サーバーは独自のキーペアを生成し、ユーザーの代わりに公開キーを公開できます。ユーザーがパートナー向けにメッセージを暗号化する場合、サーバーが公開鍵を代用したことを検出できません。サーバーはメッセージを復号化し、サーバー管理者に提示し、実際のパートナーの公開鍵を使用してメッセージ（または作成した新しいメッセージ）を再暗号化し、宛先に転送します。

ここで欠落しているのは認証局です。これは、公開鍵とユーザー名の間のバインディングにデジタル署名する信頼できるサードパーティです。このバインディングは証明書と呼ばれます。このように、サーバーが暗号化に使用する公開鍵をクライアントに提示すると、クライアントはCAの公開鍵を使用して証明書を検証し、暗号化しようとしている公開鍵が目的の受信者に属していることを確認できます。攻撃者ではありません。

ユーザーはCAを信頼する必要があります。これは、サーバー管理者を信頼するよりも口に合うかもしれません。ただし、CA証明書を保存するための改ざん防止方法も必要です。実際には、これは多くの場合、パスワードベースのMAC（メッセージ認証コード）を使用して行われます。または、CAをユーザーの秘密鍵でデジタル署名することもできます（これが行われるのを見たことはありませんが、機能します）。ただし、注意が必要なのは、信頼できないサーバーをバイパスして、信頼できるソースからCA証明書を取得することです。

秘密鍵をパスワードで暗号化する限り、それは非常に頻繁に行われ、選択したパスワードと同じくらい安全です。

または、ユーザーが帯域外で互いに秘密を共有できる場合は、公開鍵暗号化は必要ありません。クライアントは、ユーザーが選択したパスワードを使用して共有シークレットを暗号化し、暗号文をサーバーに保存できます。

于 2010-12-18T00:05:56.387 に答える
1

説明したように、このスキームは、受信者だけが読むことができるメッセージを誰かが他の人に送信できるようにするという点で合理的であるように思われます。あなたがすでに考えているかもしれないが簡潔にするために省略されているかもしれないと頭に浮かぶいくつかの項目があります：

  • 秘密鍵を暗号化するときは、PBKDF2のようなものをsaltで使用し、かなり多くの数を繰り返し使用します。
  • これはおそらく暗示されていますが、公開鍵で暗号化するのではなく、ランダム鍵（たとえば、AES-256を使用する場合は32バイトのランダムデータ）を生成することはおそらく理にかなっています。そのキーでメッセージを暗号化し、公開キーでキーを暗号化して、両方の部分を送信します。
  • 説明したように、送信者の識別はありません。純粋に匿名のメッセージを送信できます。これは意図されているかもしれませんが、そうでない場合は、何らかの識別/認証が必要になります。
  • 前のエントリと多少似ていますが、メッセージ認証については説明されていません。攻撃者は暗号化されたメッセージを変更する可能性があり、受信者はそれが変更されたことを知ることができません。ただし、テキストメッセージの場合は、文字化けしたテキストであるため、変更されていることは明らかです。ただし、データの種類によっては、変更されたかどうかを判断するのは簡単ではない場合があります。
于 2010-12-17T23:19:14.857 に答える
1

これは、hushmailが行ったことのように聞こえます。ただし、ユーザーの秘密鍵（暗号化）を持っていたため、ハッキングされたJavaアプレットをプッシュダウンするだけで、ユーザーのパスワードをサーバーに送信するという大きな問題がありました（暗号化されました）。

はるかに優れた解決策は、サーバー上にその秘密鍵をまったく持たないようにすることです。ローカルストレージがないという要件があるので、それは終わりです。

事前共有パスワードを介して対称暗号化を使用してみませんか？クライアント側のストレージなしで実行できます。これが@ericksonが彼の最後の段落で言っていたことだと思います。

于 2010-12-18T07:36:43.083 に答える
1

主な問題は、復号化コードがサーバーからダウンロードされた場合、1つ（サーバー管理者またはサーバーにアクセスしたハッカー）がこのコードを置き換えることができることです。クライアント側のユーザーはサーバーを信頼する必要がありますが、サーバーを信頼するためにサーバーを検証する方法はありません。

于 2010-12-18T08:16:02.497 に答える