アプリケーション固有の対称鍵はどこに安全に保存できますか？
アプリケーションApp1を書いています。このアプリケーションは SQLite データベースを使用しており、 AES256 を使用して暗号化する予定です。対称暗号化では、どこかに保存する必要のあるキーが必要です。
同様の質問から 私にはいくつかのオプションがありますが、私の場合は該当しません：
暗号化キーを管理者ログインに関連付けます
現在ログインしているユーザーを信頼していません。実際、私はこれを
App1以外の誰からも隠したいと思っています。暗号化キーをハードウェアに関連付けます。
App1は数千台のマシンに導入されていますが、ハードウェアを必要としないマシンもあります。起動時に暗号化キーを入力し、メモリに保存します。
ユーザーは
App1キーにアクセスできません。別のサーバーにキーを保存します。
App1の実行中は、マシンをオフラインにすることができます。同じサーバー上の別の場所にキーを保存します。
その後、それを見つけることができます。
キーをデータベースに保存します。
私の場合は一種の再帰的なデータベースを保護する必要があります。
可能な解決策は、 Windows DPAPI を使用してキーを格納することですが、
DPAPIは、ユーザーにデータ保護を提供することに重点を置いています。
一方、アプリケーションを保護する必要があります。同じマシンで異なるユーザーが
App1を使用することも必要ですセカンダリエントロピーを追加して、現在ログインしているユーザーがデータにアクセスできないように制限できます。
ただし、この秘密データをマシンに保存する必要があります。どうすればそれを保護できますか？再び再帰のようです。
質問：アプリケーション固有の対称鍵はどこに安全に保存しますか？
これはDRMの魔法の問題であり、短い答えは良い答えはないということです。1つ考えれば、非常に裕福になります。アプリケーションがキーにアクセスするためには、暗号化されていない状態からアプリケーションにアクセスできる必要があり、アプリケーションが実行できることは何でも、十分に高度なユーザーも実行できます。
TPM（トラステッドプラットフォームモジュール）またはHSM（ハードウェアセキュリティモジュール）を使用して、ユーザーがシステムに対する管理アクセス権を持たない限り、キーを保存できますが、管理者であれば、おそらく取得できます。キーを放棄するTPMまたはHSMまた、アプリケーションはユーザーが偽造できないキーストアに対して自分自身を認証する方法がないため、TPMまたはHSMに操作を実行させることができるのはプログラムだけであることを確認することは困難ですが、少なくとも保持します。キー自体は安全です。
簡単に言えば、アプリを実行するボックスの管理者がユーザーにいる場合、あなたは完全に不運です。限られたアカウントのみを与えることができる場合、いくつかのオプションがありますが、システムをかなりロックダウンしない限り、それらはまだ特に強力ではありません。
HSMは良い方法です。残念ながら、FOSSの実装については知りません。私は時々私自身の「何もないよりもはるかに良い」HSMをすることを考えました。 FIPS認定またはセキュリティシール付きのエポキシで包まれたものではありませんが、ボックスに座っているだけのキーよりも優れています。
HSMの良い点は、ホストがキーを要求/使用することとは関係なく、キーへのアクセスを監査できることです。マシンの再起動またはそれを必要とするプロセスが開始されていないときにキーが取得された場合、調査の理由があり、おそらくキーを変更することになります。
最も可能性の高い解決策はサーバーの秘密の場所にキーを保存することになるため、SELinuxを使用して、承認されたユーザー/セキュリティコンテキスト以外のすべてがキーを読み取らないようにすることをお勧めします。
また、auditdを使用して、キーを含むファイルに特別な監査ルールを配置し、ファイルが読み取られるたびに追跡できるようにすることをお勧めします。監査ログをホスト外のログ収集ホストに送信することを強くお勧めします。これにより、HSMの監査能力がある程度得られます。
Windows暗号化サービスプロバイダーのキーストアは、非対称キーのみを保存できます。なぜマイクロソフトがこのように設計したのかは非常に良い質問です。それでも、あなたの唯一の解決策はHSMを使用することです。アプリケーションキーは、作成したデータストアに格納し、HSMに格納されているマスターキーで暗号化します。
最近のほとんどのHSMは、API呼び出しのPKCS＃11構文をサポートしています。 HSMは、PCIカードおよびスタンドアロンボックスとして入手できます。全体的なことも考慮する必要があります
PCIまたはスタンドアロンオプションを選択する前にクリプトが必要です。
また、HSM管理機能をサーバーおよびデータベース管理者から分離します。アプリケーションの暗号化と機密データの処理を開始すると、InfoSecの基本原則である職務の分離が実現します。
暗号化は技術であり、誰でも暗号サービスプロバイダーAPIを呼び出すことで暗号化できることに注意してください。暗号化とは、キーを安全に生成し、データを安全に暗号化および解読し、キーを安全に格納し、不正アクセスを防止してキーをローテーションするプロセス全体です。暗号化を無計画に適用すると、誤った安心感が与えられます。
場合によります。
要件2は、HSMを含むハードウェアベースのソリューションを排除します。
保護するユーザーの種類を正確に説明していません。あなたが書いた私は誰からもこれを隠したい。 anyoneによってシステム管理者も意味する場合、解決策なしがあります。権限の少ないユーザーを意味する場合、adminsではなく、解決策がある可能性があります。リソース（ファイル、レジストリエントリなど）を作成し、そこにキーを保存できます。このリソースへのアクセスは、アプリケーションが実行されているアカウントにのみ付与してください。そうすると、そのようなユーザー（管理者を除く）はキーにアクセスできなくなります。ただし、管理者は権限を変更したり、キーにアクセスしたりできます。
以下についてはどうですか？
1）公開鍵と秘密鍵のペアを作成します。
2）公開鍵で対称鍵を暗号化し、それをコードに格納します。
3）プログラムで読み込まれる起動時に秘密鍵を提示します（コマンドラインにコピー/貼り付け）。
これの欠点は、プロセスが手動であり、「所有者」がプログラムを起動する人でなければならないことです。
利点は、秘密鍵がローカルメモリに格納され、暗号化されている場合は、復号化に使用されたら削除できるという点で、セキュリティが得られることです（Javaでは、byte []を使用してから消去します）。