AES
AES はまだ公式の「Avanced Encryption Standard」であるため、対称暗号には依然として非常に適しています。より長いキー サイズによる速度の低下は、セキュリティの向上に比べて無視できます。
全体的なアプローチ
まず第一に、アプローチ自体は健全に思えます。ただし、データベース内の暗号化されたデータがもたらす欠点を念頭に置いておく必要があります。より効率的なインデックス作成、クエリの最適化、一般的な選択的なクエリはありません...データベースの大部分またはデータベース全体を暗号化する場合は、次のことを行う必要があります。データベース自体が提供する暗号化機能をよく調べてください。このアプローチを使用する場合は、SSL/TLS を使用してデータベースへの接続をさらに保護する必要がありますが、これは見過ごされがちです。これにより、求めている追加のセキュリティを提供しながら、「通常の」データベースのすべての利点が維持されます。
キーを紛失したというあなたの意見は正しいです。その場合、あなたは大きな問題に直面しています :) しかし、すべてが失われたわけではありません。JCEKS キー ストア ファイルのパスワードをブルート フォース攻撃することもできます...
そのリソースに私たちをもたらすもの。これは、キー ストアとパスワードに関する鶏と卵の問題です。これに対する唯一の本当にクリーンな解決策は、アプリ/データベースを起動するたびにパスワードを手動で入力することです。しかし、これは実際の問題になる傾向があるため (真夜中のクラッシュを考えてみてください)、パスワードをファイル システム上のテキスト ファイルに保存する傾向があります。いくつかのガイドラインに従う限り、それは許容されます。
- 理想的には、このファイルは、アクセスが制限された別のマシン上にあります
- 同じマシン上にある必要がある場合は、そのフォルダーへのアクセス許可を制限します-ただし、アプリがアクセスできるようにすることを忘れないでください
- そのファイルを再度暗号化することは、通常は役に立ちません。鶏と卵の問題が再び発生します。コンテンツを BASE64 でエンコードすることは、技術に精通していないユーザーに対する最初の防御策として有益な場合があります。
- パスワードを知っている人はほとんどいないはずです (十分に頻繁に言うことはできません)。
- パスワードのバックアップを安全な場所に保管してください。
- キー ストア ファイルの急増を何としても回避する
本当に厳密にしたい場合 (パスワードを知っているのは 1 人か 2 人だけだとしましょう)、さらに秘密共有スキームをインストールすることもできますが、要件によってはやり過ぎになる可能性があります。このようなスキームは、秘密の (それ自体は役に立たない) 部分を持つ個人が、実際の秘密を復元するために部分を結合できるようにします。このようにして、パーツをより大きなグループに分散することで、損失のリスクを軽減できます。
