キーをハードコーディングせずに、Javaでデータを復号化するにはどうすればよいですか？
これがニワトリの卵の問題やホイールの再発明ではないことを願っていますが、ここに行きます。
Javaアプリケーションがあり、パスワードで保護されたファイルにアクセスする必要があります（実際にはアプリケーションの起動時に）。
アクセスすることになっているパスワード保護ファイルのパスは構成ファイルにあり、encryptedパスワードもこの構成ファイルにあります。
問題は、ファイルにアクセスできるように暗号化されたパスワードを復号化する方法ですか？
コードに復号化キーをハードコードして、それを復号化することができました。
プロ：
- できます
短所：
- コードが難読化されていないため（さまざまな理由で不可能ではない）、解読キーが見つかるため、使用できません。
- 復号化はアプリケーションにハードコードされるため、パスワードは変更できません
注：私は主に（1）;に関心がありますが、（2）は望ましいが私には必要ありません。
これには良い/標準的なアプローチがありますか？
どんな入力でも大歓迎です。
a "password"（または、パスワードを復号化するためのパスワード、またはパスワードを復号化するためのパスワード）をどこかに保存する必要があります。
だから、あなたはそれを保存することもできます
- コンピューター上では、解読して読み取ることができます（プログラムで実行できる場合は、anyプログラムで実行できます）。
- またはユーザーの頭の中（プログラムで取得するのは困難ですが、独自の一連の問題があります-
12345、ポストイットノートなど） - または、ユーザーが携帯するデバイス内（紛失/盗難の可能性が高い、より高価）
保護しているもの（銀行の金庫室やlolcatの写真など）に応じて、これらのアプローチを組み合わせたり、個別に使用したりできます。また、パスワードの強度に加えて、暗号化の強度も考慮する必要があります。「背面に窓がある庭の小屋にある金庫室のドアを使用しても意味がありません」。
根本的には、これはコントロールに関する問題です。このKeyStoreファイルへのアクセスを制御して、アプリケーションだけがアクセスできるようにして、他の誰もアクセスできないようにする必要があります。許可されていないアクセスの可能性が開かれるため、これに適用するコントロールを少なくしすぎないようにしてください。あまりにも多くのコントロールを配置したくありません。これは、扱いにくく、使用するには高すぎるからです。
アプリケーションではなく他のアプリケーションがそのKeyStoreにアクセスできるようにするには、アプリケーションがIDをアサートできるようにする必要があります。
次のオプションがあります。
- パスフレーズを構成ファイルのキーストアに入れ、起動時にアプリケーションにこれを読み取らせます。これにより、ファイルシステムのアクセス許可を操作することにより、アプリケーションインスタンスのIDを制御できます（アプリケーションユーザーは読み取りはできるが、書き込みはできず、他のユーザーは読み取りができません）。 KeyStoreがKeyStoreファイルのみに基づいている場合は、KeyStoreファイルにOSアクセス許可コントロールを配置し、パスフレーズを完全に削除することを検討してください。敵対者がアプリケーションユーザーになりすますことができる場合、彼らはあなたのシステムに根を下ろしており、より大きな問題を抱えています。
- アプリケーションが起動したら、アプリケーションがキーストアをロードする前に、誰かがコンソールでキーストアへのパスフレーズを入力してください。これは明らかに「厄介な」カテゴリに分類されます。自動化された起動を妨げ、パスフレーズを知っている必要のある人物に賄賂を贈ることによって攻撃される可能性があります。
- ハードウェアセキュリティモジュール（HSM）を使用してKeyStoreをバックアップします。これにより、アプリケーションサーバー上のファイルシステムの破壊を、キーを使用する前にホスティングファシリティに対する物理的な攻撃と組み合わせる必要があります。 HSMへのログインに使用される資格情報のセキュリティに関する上記と同じ考慮事項。これは私が生計を立てるためにHSMを販売していることを開示しなければならない場所です。
- アプリケーションを開始する前に、複数のオペレーターがハードウェア資格情報（スマートカード）を提供し、システムコンソールにパスフレーズを入力する必要があるように、HSMをHSM強制アクセス制御と組み合わせて使用します。これは「面倒」の遠端ですが、上記2.の贈収賄問題から保護します。
これらはいずれも暗号化レイヤーの追加に基づいていないことに注意してください。すべては、アプリケーションインスタンスのIDまたは1つ以上のオペレーターによる承認に基づいて、キーストアコンテンツへのアクセスにコントロールを適用することです。
結局のところ、それはすべて、秘密鍵の重要性と、その秘密鍵を紛失または侵害した場合の結果に依存します。使用するコントロールは、リスクと結果の評価に基づいたビジネス上の決定です。
誰に対してこのファイルを保護していますか？
同じまたは少ないアクセス許可で実行されているプロセスに反対する場合は、 Java.security.KeyStore は、ユーザーがプロセスに自分の選択したパスワードでキーにアクセスすることを承認できるようにする必要があります。それでも、その承認プロンプトに対して 信頼できるパス を確立する必要があります。
スーパーユーザーとして実行されているプロセスやウィンドウシステム全体のUIイベントをインターセプトする機能を使用してプロセスを保護しようとしている場合は、パスワードで保護されたキーストアをあきらめる必要があります。
パスワードはユーザーの秘密鍵を保護するため、秘密鍵を使用する前に、ユーザーによる使用が許可されていることを確認する必要があります。アクセスがユーザーによって許可されていることを確認する最も論理的な方法は、パスワードを要求することです。したがって、これがどのように問題になるかを理解することは困難です。
これは、セキュリティに関する長年の問題の1つであるようです。パスワードをプレーンテキストにしたくないのは、JADを使用してパスワードを実行し、接続文字列を確認すると、最も印象に残りません。そのため、難読化されているかどうかに関係なく、通常、アプリケーションに格納することは好ましくありません。とは言っても、パスワードはどこかに、通常は構成（プロパティー・ファイル）の一部として、またはシステムが使用するデータベース内に保管する必要があります。
プロパティファイルアプローチでは、それを必要とするユーザー、グループに属しておらず、必要に応じてRX特権またはRWしか持たない非特権Webサーバーアカウントのみが読み取る必要があります。ここでの問題は、アプリケーションが2番目に読み取った2番目の問題です。誰でもそれを取得できますが、それは必要です。
データベースに関しては、別の一連の問題があります。攻撃者がデータベースを実行している非特権ユーザーアカウントを侵害した場合、これはWebサーバーであってはなりません。Webサーバーの資格情報にアクセスできるため、2つのシステムの価格が低下します。 1。これは、初期のシステム設計の欠陥を証明するため、危険にさらされる悪い方法です。