ユーザーパスワード（AES）付きの秘密鍵（RSA）

Question

ASP.NET Coreアプリケーションの一部のデータを大幅に暗号化する必要があります。

アイデアは： ユーザーにハッシュパスワードが設定されます。ユーザーには、非対称キー（RSA-512）もあります。公開鍵はDBに格納されます。秘密鍵は、最初に対称鍵（AES-256）で暗号化されます。この暗号化の鍵として、ユーザーのプレーンテキストパスワードを使用します。

車のエンティティを例として作成したい場合は、この特定の自動車エンティティの公開鍵と秘密鍵を生成します。公開鍵はプレーンテキストで保存されます。秘密鍵は、 'car'（ユーザー）の作成者の公開鍵で暗号化されます。

車に属するフィールドは、車の公開キーで暗号化されています。

車を復号化する。ユーザーの秘密鍵が必要です。これは、車の秘密鍵を復号化するために必要となるためです。この解読された車の秘密鍵で車の内容を解読することができました。

しかし、ユーザーの秘密鍵になるためには、プレーン/テキストパスワードで復号化する必要があります。このパスワードは@ログイン時に1回のみ利用できます（それはどこにも保存されていません）。

私が今問題にしているのは、私がIdentityServer 4で連携ログインシステムを使用しているということです。これは、私のAPIプロジェクトとは異なる「プロジェクト」です。

しかし、これは私の 'ビジネスロジック'を実行するため、APIでパスワードが必要です。

本当の問題はここから：

この問題を解決するには：

私は、ログインプロジェクトを呼び出すことができます私のAPIの「ルート」を追加することを考えていました。 ユーザがログインするたびに、正しいAPIへのREST呼び出しをメッセージとして実行します：「ここでは、ユーザXの秘密鍵の復号化されたバージョンです」。

この時点で、APIは「InMemory」EFコアデータベースにAPIを保存します。ユーザが自分の車のデータを解読する必要があるたびに。私は 'InMemory' DBから秘密鍵を取得する必要があります。

問題私はここにいます。この目的のためにEFの「InMemory」DBが使用されていますか？デモやテスト目的としてのみ使用されているようです。

メモリのプライベートキーはいつ削除しますか？ユーザーがログアウトすると、私はそれを管理することができます。しかし、ユーザーが「期限切れになったとき」私はこれをトリガーすることができません。だから彼の解読された秘密鍵は記憶に残っています。

「InMemory」DBの信頼性はどれくらいですか？それはいつ自分自身を清めますか？

便利なヒントをお待ちしています。

敬具、ブレヒト

Answer 1

さておき、セキュリティ上の問題（コメントを参照）、インメモリデータベースは、テストまたはDB-以下のチュートリアルのために主に存在しています。あなたがそれに追加するものはすべて、deletedまで残っています（何回かガベージコレクトされていますが、実際に制御できません）。あるいはDbContextが破棄されます。

InMemory EFコアデータベースの代わりに、メモリキャッシュ（分散またはローカル）を使用する方が理にかなっています。

もちろん、Redisのような分散キャッシュを使用して、デコードされた秘密鍵を安全に保ち、あなたのサービスから呼び出すことができます。キーが無効化され、要求される必要があるか、またはキー上でexpire commandを呼び出して期限を延長する必要があるときにexpiryの日付を追加できます。ユーザーがログアウトすると、delでキーを削除します。

サーバの規模を拡大するとうまくいきます。 Microsoft.Extensions.Caching.Memoryで始める場合は、両方ともIDistributableCacheインターフェイスを実装しているので、後でRedisに簡単に切り替えることができます。スタートアップクラスの設定を変更するだけです。

また、.NETコアに直接実装されていないが、余分なパッケージhereとして入手可能なSecureString（hereを参照）を試して、ローカルメモリにできるだけ短くし、 GCはある時点でそれを行います。