サーバーに秘密鍵を保存し、k1を使用してログインし、k2を使用してHMACを検証し、k3を使用して秘密鍵を復号化します

Question

私は、次のようなプロセスを使用してエンドユーザーが簡単に電子メールを暗号化するための概念実証プログラムに取り組んでいます。

アカウントを作成するには：

ランダムソルトとIVを生成し、ユーザーからパスワードを取得します。
PBDKF2-HMAC-SHA512（またはscryptか？）で384ビットの鍵を生成します。
それを3つの128ビットキー（k1、k2、k3）に分割します。
RSAキーペアを生成します（ [〜＃〜] gpg [〜＃〜] の場合）。
秘密鍵をk3で暗号化します。
K2を使用して、暗号化された秘密鍵のHMACを生成します。
ソルト、IV、k1、反復回数、公開鍵、HMAC、および暗号化された秘密鍵をサーバーに送信します。

ログインします：

サーバーにソルトと反復回数をリクエストします（メールアドレスの漏洩を防ぐために、ここで何かを行う場合があります）。
PBKDF2でk1、k2、k3を再生成します。
サーバーにk1を送信します。サーバーは、保存されているバージョンと照合します。これは、暗号化されたキーを公開しないようにするために使用されます。理論的にはこれは問題になりませんが、万が一に備えて暗号化されたデータを保護する方が良いようです。
K1が一致した場合、サーバーは、HMAC-SHA-1 MACを使用して、AES-128暗号化秘密鍵とIVを送り返します。
K2を使用してHMACを確認します。
K3を使用して秘密鍵を復号化します。

サーバーには公開鍵があり、秘密鍵があるので、将来のログインでは簡単にできます。

サーバーが危険にさらされたとしても、サーバーが持つ唯一の情報はk1、salt、IV、および暗号化された秘密鍵ですが、鍵をいじくるにはk2が必要で、鍵を復号化するにはk3が必要です。。

クライアントはキーを一度だけ復号化する必要がある（そしてそれをオペレーティングシステムのキーリングに保存できる）ため、反復回数は非常に多くなる可能性があります。

これにより、サーバーが危険にさらされた場合にクライアントを保護できると思いますか？残っている唯一の攻撃ベクトルは、クライアントのハッキング、パスワードのブルートフォースの強制（PBKDF2の多くの反復を使用できるため、信じられないほど難しいはずです）、ゴムホース暗号解読です。

編集：より具体的には、攻撃者がサーバーの所有者と協力している場合でも、これはユーザーのパスワード、秘密キー、および暗号化された電子メールを攻撃者から保護することを意味します。暗号化されていないメールを保護することは基本的に不可能です。サーバーを制御している攻撃者は、受信したメールをすべて保存することができるためです。ソーシャルエンジニアリングとゴムホース暗号解読が関連しますが、私の目標は、可能な攻撃を可能な限り減らすことです秘密にしてはいけません。

bethlakshmi · Answer

いくつかの問題があります：

1-ログイン順-ステップ＃4-サーバーでの確認のためにk1を送信しています。サーバーにはk1のコピーがありません。アカウント作成スレッドによると、ステップ3（k1、k2、k3を生成）はおそらくクライアント側で発生し、サーバー送信の一部ではありません（ステップ7）

2-k1を格納する場合、それは事実上パスワードです。ログイン手順4に進むために必要なのはk1値の繰り返しだけです。

3-攻撃者とユーザーを模倣する機能の間に立っているのは、秘密鍵のAES 128ビット暗号化です。これはサーバーに保存されるため、サーバーがクラックされた場合、暗号化されたキーを取得できます。 k1も提供する場合、追加データを取得する機能を提供する場合があります。攻撃者が勝利するコンボを見つけるまで、基本的に2つの可能な計算があります。

AES復号化（test-k3、暗号化された秘密鍵）=暗号化された電子メールを復号化できる鍵を作成します。
pBDKF2-HMAC-SHA512を使用した鍵生成（塩、＃対話、テストパスワード）= k1（既知）、k2（不明）、k3（不明）

さて、問題は「それらのことはどれほど簡単か」という領域に入りました。本当に分からない。これは、crypto.SEにとって良い質問です。私たちは暗号の難しさの世界に入り込んでいますが、これは私の強い訴訟ではありません。

4-サーバーの送信とコロケーションを監視することの価値を否定しないでください。添付ファイルがアカウント/ログインサーバーをハッキングした場合、そのサーバーには他に何がありますか？メールまたは認証後の特権ユーザーのトランザクションも提供している場合、問題は上記の手順ではなく、他の重要な資産です。また、ユーザーがログインしたとき、およびユーザーの行動の一般的なパターン、試行錯誤を見ると、暗号化ハッキングの厄介な数学的部分が無関係である十分なソーシャルエンジニアリング情報が得られます。サーバーを壊し、ユーザーに電話して謝罪し、電話でパスワードを教えてもらえるなら、暗号をハッキングする作業は時代遅れです。

KeithS · Answer

考慮すべきいくつかのこと：

特定された攻撃ベクトルは何ですか？別の言い方をすれば、情報セキュリティに対する特定の種類の侵害を防止しようとしていますか？
あなたの計画は非常に複雑です。スキームが複雑になればなるほど、可動部分が増え、弱点が増える可能性が高くなり、作品を簡単に作成することが容易になります。特定された攻撃ベクトルから身を守る簡単な方法はありますか？
ここでの制限要因は、ユーザーのパスワードの強度と、ソーシャルエンジニアリングに対するユーザーの感受性です（ゴムホース暗号である必要はありません）。これらはチェーン内の弱いリンクなので、できることは、それが唯一の弱いリンクであることを確認することです（そのため、攻撃者があなたのせいではありません）。

より具体的には、このスキームの技術的側面：

別のMACを持つことは弱点です。チェックは秘密キーの復号化と統合されていないため、暗号化モードによっては、攻撃者がクライアントソフトウェアを復号Oracleとして乗っ取り、秘密キーを回復する可能性があります。 HMACのチェックとメッセージの復号化を統合する認証済み暗号モードの使用を検討してください。
上記の結果として、ダイジェストしている暗号文を暗号化するために使用したものとは異なるキーを使用してHMACを計算することにはほとんど価値がありません。 DBのデータを変更できる攻撃者は、HMACまたはキーのいずれかをスクランブルすることで、ログインを汚すことができます（ソーシャルエンジニアリングを有効にしてアカウントを「回復」させることにより）。シークレットは不要です。暗号化されたキーを解読するためにHMACを解読する必要がないため、秘密キーを取得しようとする人はHMACをまったく気にしません。したがって、k2とk3を単一の256ビットキーに組み合わせて、認証モードを使用してRSA秘密鍵を暗号化することを検討してください。
このスキームでは、サーバーはデータの照合以外は機能せず、クライアントとサーバー間のトラフィックのセキュリティ保護については言及していません。したがって、このスキームは、送信されるパスワードハッシュ（k1）の生成に使用されるシークレットを知らなくても、着信ログインリクエストを監視して再生することでデータダンプを取得するために利用できます。これを軽減するために、クライアントとサーバー間の安全な接続を要求することを検討してください。