web-dev-qa-db-ja.com

複数のユーザーがいる場合に暗号化キーをログインに関連付ける方法

シナリオ:

ユーザーA、B、Cは、Webアプリケーションから暗号化されたデータにアクセスする必要があります。それらはすべて同じデータにアクセスします。

暗号化キーは、サーバーに保存されないように、ログインに関連付ける必要があります。

質問:ユーザー名とパスワードがすべて異なる場合でも、ログインの詳細にキーを関連付けることはできますか?このシナリオでの最良のアプローチは何ですか?

2
IMB

一般に、これを行うソリューションは次のように機能します。自分で構築しようとするのではなく、すでにこれを実行して使用している信頼できるシステムを見つける必要があります。

  1. 最初に、対称鍵を生成します。これはマスターキーであり、ユーザーには直接表示されません。攻撃者がキーに到達する可能性がある場所には、このキーを(プレーンテキストで)保存しないでください。
  2. マスターキーを使用してデータを暗号化し、理想的には整合性のためにHMACを使用します(またはGCMモードでAESを使用するなど、整合性を保証する他の方法を使用します)。
  3. パスワード検証に使用されているものとは異なるパラメーター(異なるソルトなど)を使用して、キー導出関数(PBKDF2やscryptなど)を通じてユーザーのパスワードを実行します。これらPassword-Derived Keysをどこにも保存しないでください。
  4. 各ユーザーのパスワード派生キーでマスターキーを1回暗号化します。マスターキーのこれらの暗号化されたコピーを、関連する各ユーザーのアカウントデータと共に保存します。

データにアクセスするには:

  1. ユーザーを認証します。 (これは通常、アカウントのパスワード検証パラメーターを取得し、それらのパラメーターを使用してパスワード検証を生成するキー導出関数を介してパスワードを実行し、そのパスワード検証がそのユーザー用に保存されているものと一致するかどうかを確認することを意味します。)
  2. ユーザーのパスワード派生キーを取得します。 (KDFパラメーターの2番目のセットを取得し、それらのパラメーターを使用してパスワードをKDFに渡します。パスワードが正しいことはすでにわかっているため、何もチェックせずに、再生成されたキーが正しいことが期待できます。)
  3. パスワード派生キーを使用して、マスターキーを復号化します。これを行った後、できるだけ早く、パスワードから派生したキーをメモリから削除します。
  4. 復号化されたマスターキーを使用して、データのHMACを確認(または、整合性を確保)してから、データを復号化します。
  5. 復号化されたマスターキーをメモリから消去してデータにアクセスする(この場合、データを変更して変更を保存する場合は、手順2〜4を繰り返す必要があります)、または復号化されたマスターキーを安全に保持するあなたが配置できるようにメモリの。
  6. 復号化されたマスターキーと復号化されたデータをできるだけ早くメモリから削除します。

ユーザーのパスワードを変更するには:

  • ユーザーが古いパスワードを持っている場合(パスワードローテーション)、古いパスワードを確認し、それを使用してユーザーの現在のパスワード派生キーを生成し、それを使用してマスターキーを復号化します。新しいパスワードを使用して、ユーザーの新しいパスワード派生キーを生成し、それを使用してマスターキーを再暗号化します。古い暗号化されたマスターキーを新しい(ユーザーのアカウント情報にある)マスターキーで置き換えます。
  • ユーザーが古いパスワードを忘れた場合は、管理者に他の方法でユーザーの身元を確認してもらい、ユーザーに新しいパスワードを選択してもらいます。次に、管理者に独自のパスワードを入力し、独自のパスワード派生キーを取得して、暗号化されたマスターキーの独自のコピーで使用することにより、復号化されたマスターキーを取得します。ユーザーの新しいパスワードを使用して、ユーザーの新しいパスワード派生キーを生成し、それを使用してマスターキーを暗号化します。新しいキーで暗号化されたマスターキーをユーザーのアカウント情報に配置し、古い(忘れた)パスワードから派生したキーを使用して暗号化されたマスターキーを置き換えます。

ユーザーを管理するには:

  • 新規ユーザーの場合、基本的には上記の「パスワードを忘れた」場合のフローに従ってください。
  • ユーザーを削除したり、データへのアクセスを取り消したりするには、そのユーザーのパスワード派生キーを使用して暗号化されたマスターキーのコピーを削除します。これにより、ユーザーは自分のパスワードを使用してマスターキーを取得することができなくなります。

詳細(システムの理解を助けるためにのみ存在します)にもかかわらず、[〜#〜]ください[〜#〜]これを自分で実装しようとしないでください。欠けているか、やっと言及されただけの多くの重要な詳細があります。たとえば、ユーザーがマスターキーを直接見ないことが重要です(そうしないと、マスターキーのコピーを保存でき、キー構造全体を再生成してデータを再暗号化せずにアクセスを効果的に取り消すことができなくなります)。これらの詳細の多く(メモリ内の安全なキーストレージなど)はプラットフォームに依存します。

さらに、暗号プリミティブのライブラリ実装を使用している場合でも、暗号自体を台無しにする多くの方法があります。キーまたはキー派生パラメーターを誤って生成し、誤ったプリミティブを選択した場合、またはサイドチャネル攻撃に対して脆弱な方法でいずれかのステップを実装した場合、スキーム全体が危険にさらされる可能性があります。このことを自分で考えようとしないでください。暗号化の実装について知識のある誰かがすでにまとめたもの、そして知識のある他の誰かがレビューしたものを使います。

4
CBHacking

アプリケーションの詳細に大きく依存しますが、大まかに言えば...

ユーザーごとに公開鍵/秘密鍵のペアを生成できます。対称鍵を使用してデータを暗号化してから、その対称鍵を各ユーザーの公開鍵で暗号化します。個別に暗号化された単一の対称キーのコピーを保存し、ログイン時にそれらを各ユーザーに、および(対称的に)暗号化されたデータの単一のコピーをそれらに戻します。

ユーザーは秘密鍵を使用して対称鍵のコピーを復号化し、それを使用してデータを復号化します。

警告-私は、このアプローチをアプリケーションにとって実行不可能にする可能性のあるあらゆる種類の懸念をここで手を振っています。これまでに「独自の」暗号プロトコルを使用する前に、地域のセキュリティ専門家に相談してください。しかし、そうは言っても、上記の大まかなアウトラインは、あなたが求めていることを実行するはずです。

0
JesseM