秘密鍵を保存する場所は？

ソフトウェアの一部を暗号化するとします。たとえば、データベースなどの資格情報。これらの値をどこかに保存する必要がありますが、クリアテキストで保存すると、攻撃者が簡単に不正アクセスを取得できます。

ただし、クリアテキストを暗号化する場合、キーはどこに保存しますか？難読化のレベルに関係なく、ソフトウェアがアクセスできるものはすべて、意欲的な攻撃者はアクセスできます。

• キーがファイルシステムのセキュリティモデルによって保護されているとします。しかし、（悪意のある）スーパーユーザー、またはそのような忠実度を提供しないプラットフォームはどうでしょうか？
• または、キーはソフトウェアバイナリにハードコードされていますが、常にデコンパイルできます。オープンソースソフトウェアや解釈されたコードについてはどうでしょうか。
• キーが生成される場合、そのようなアルゴリズムは決定的（おそらく）である必要があり、同じ問題がシードに適用されます。
• 等

暗号化は、チェーン内の最も弱いリンクと同じくらい強力であり、これはかなり緩いもののようです！それが仕事にふさわしいツールだと思い込んで（ユーモア）、そのような情報を堅牢に保護するにはどうすればよいでしょうか？

ジョブに適したツールについて：おそらく、たとえば-サービスアクセス（DB、認証サーバーなど）の場合、サービスアカウントを使用してこの層でのアクセスを制限します。監査などのように、クリアテキストで資格情報を持っていることはそれほど心配ではありません。

しかし、私にはそれでも不十分だと思われます。だれもいるべきではないところをぶらぶらしたくないのです！

まず第一に、私は自分をセキュリティの専門家と呼ぶつもりはありませんが、私はこの質問に答えなければならない立場にありました。私が見つけたものは少し驚いた：完全に安全なシステムのようなものはありません。まあ、完全に安全なシステムは、サーバーがすべてオフになっているシステムだと思います:)

当時私と一緒に仕事をしていた人が、侵入者に対する水準を上げるという観点から安全なシステムを設計することを説明しました。したがって、セキュリティ保護の各レイヤーは、攻撃の機会を減らします。

たとえば、秘密鍵を完全に保護できたとしても、システムは完全に安全ではありません。ただし、セキュリティアルゴリズムを正しく使用し、パッチを最新の状態に保つと、レベルが上がります。しかし、はい、十分に強力で十分な時間を与えられたスーパーコンピューターは暗号化を破ることができます。このすべてが理解されていると確信しているので、質問に戻ります。

質問は明確であるため、まず各ポイントに対処しようとします。

キーがファイルシステムのセキュリティモデルによって保護されているとします。しかし、（悪意のある）スーパーユーザー、またはそのような忠実度を提供しないプラットフォームはどうでしょうか？

はい。Windowsキーストアやパスワードで暗号化されたTLS秘密キーなどを使用する場合、秘密キーへのパスワード（またはアクセス）を持つユーザーに公開されます。しかし、私はあなたがレベルを上げることに同意すると思います。ファイルシステムACL（適切に実装されている場合）は、非常に優れたレベルの保護を提供します。そして、あなたは個人的に精査し、スーパーユーザーを知る立場にあります。

または、キーはソフトウェアバイナリにハードコードされていますが、常にデコンパイルできます。オープンソースソフトウェアや解釈されたコードについてはどうでしょうか。

はい、ハードコードされたキーをバイナリで見ました。繰り返しますが、これはバーを少し上げます。このシステムを攻撃する人（Javaの場合）は、Javaがバイトコード（など）を生成することを理解する必要があり、それを逆コンパイルする方法を理解しなければなりません。マシンコードに直接書き込む言語を使用している場合、これによりバーが少し高くなることがわかります。これは理想的なセキュリティソリューションではありませんが、ある程度の保護を提供できます。

キーが生成される場合、そのようなアルゴリズムは決定的（おそらく）である必要があり、同じ問題がシードに適用されます。

はい、基本的に、アルゴリズムは秘密鍵を作成するための秘密鍵情報になります。したがって、保護する必要があります。

したがって、セキュリティポリシーであるキー管理の中心的な問題を特定したと思います。鍵管理ポリシーを適切に設定することは、安全なシステムを提供するために重要です。そして、それはかなり広いトピックです。

質問は、システム（および秘密鍵）がどれだけ安全である必要があるかということです。システムで、バーをどれだけ高くする必要がありますか？

さて、あなたが喜んで支払うなら、これに対する解決策を生み出す人々がいます。HSM（ハードウェアセキュリティモジュール）を使用することになりました。基本的に、ハードウェアにキーを含む改ざん防止サーバーです。このキーを使用して、暗号化に使用される他のキーを作成できます。ここでの考え方は、（正しく構成されていれば）キーがHSMから離れないということです。HSMには多くの費用がかかります。ただし、一部のビジネス（クレジットカードデータの保護など）では、侵害のコストははるかに高くなります。だから、バランスがあります。

多くのHSMは、機能のメンテナンスと管理からキーカードを使用します。キーを変更するには、定足数のキーカード（5つのうち9つ）をサーバーに物理的に配置する必要があります。そのため、スーパーユーザーのクォーラムが共謀した場合にのみ侵害を許可することで、これにより水準がかなり高くなります。

HSMに同様の機能を提供するソフトウェアソリューションがあるかもしれませんが、私はそれらが何であるかを知りません。

これは質問への回答に役立つだけですが、これが役立つことを願っています。

あなたがしたいことはできません。

キーがファイルシステムのセキュリティモデルによって保護されているとします。しかし、（悪意のある）スーパーユーザー、またはそのような忠実度を提供しないプラットフォームはどうでしょうか？

基本的に、悪意のある人から保護する必要があります。モデルでは、ある時点で誰かがキーにアクセスできます。その人が悪意がある場合はどうなりますか？あなたが悪意がある場合はどうなりますか？ご覧のように、キーをまったく持たないことを除いて、問題を解決することはできません。

そのため、データベース資格情報ではなく、他の認証メカニズムでは機能しません。しかし、何であれ、ある時点で誰かがデータにアクセスする必要があり、その誰かが悪意を持つ可能性があります。

これは、作成されたのと同じレベルでは実際には解決できない問題の1つです。いくつかの基本的な哲学に戻って、解決を期待してカスケードをたどる必要があります。

最初の哲学は「決してクライアントを信頼しない」であり、密接に関連する「本当に秘密を守りたいのなら、誰にも言わないでください！」です。

簡単な例は、前述のデータベース資格情報です。明らかに、クライアントにアクセスしてもらいたいが、ランダムなインターネットストレンジャーにはアクセスさせたくないので、何らかのID /検証/ログインシステムが必要です。しかし、これを隠すことの核となる前提は問題です。ユーザー自身が秘密を所有しなければならないが、その秘密が何であるかを知りたくない場合、あなたができることはそれを隠すか、開けないようにすることだけです秘密のパッケージ」。しかし、彼らはまだ見つけることができるので、バックアップ計画を立てた方が良いでしょう！

最も簡単な解決策は、「それをしないで」です。ユーザー自身のアカウント資格情報を使用して、ソフトウェアのデータベースへのクライアントレベルのアクセスを許可します。クライアントが悪意を持つようになった場合、最悪のシナリオは、クライアントが自分のデータを台無しにする可能性があることです。それでおしまい。データベースとシステムには、せいぜいそのクライアントからのジャンクエントリが含まれているだけで、そのクライアント専用であり、他の誰（あなたを含む）が騒乱に苦しんでいることはありません。

デプロイされたソフトウェアに何かをさせたいだけで、世界中の誰もが同じことをやり取りできるわけではない特定のユースケースがありますが、そのためには秘密を隠しているだけで、それをする唯一の正当な理由は頭痛やシステム活動を減らします。隠された情報が一般的な知識になると、ゲームを壊すことはなく、最悪の場合は迷惑になります。

これらの狭いユースケースのいずれかを使用している場合、それは単に難読化に関するものであり、それはすべて創造性を高めることです。あなたがパズルを作成している人を除いて、それは本当にコードゴルフによく似ています。それが本当にそれだけです-パズル。そして人々はパズルを解くことを好むので、だれかがそれを理解したら大丈夫です。

しかし、世界の大部分の場合、ユーザーから秘密を守らなければならないことを心配せずに操作するのが最善です。代わりに、ベストプラクティスは、ユーザーにシークレットを許可し、それを保護する責任を負わせて（たとえば、ユーザー名とパスワード）、シークレットが流出または悪用された場合に発生する危険性を制限することです。

真の「鍵管理」暗号化/セキュリティコンテキストでは、「秘密鍵を保存する場所」の答えは「どこか他の場所」です。暗号化はポイントツーポイント保護であり、公開鍵と秘密鍵の暗号化は時間と空間を通過する情報を保護するように設計されています。秘密鍵は本質的に脆弱であり、それを保護することは暗号化の重複の問題ではなく、完全にアクセスから保護します。また、システムがシステムにアクセスする必要がある場合、システム自体を保護する必要があります。クライアントのマシンではできません。いつでもVMを実行し、RAMをダンプし、ネットワークトラフィックをスニッフィングし、プロキシまたは仮想NICをインストールし、実行可能ファイルを逆コンパイルできます...その負けた戦いに自発的に関与しないでください。

秘密を保存する必要があるのが実際にソフトウェア自体の使用を制御することに基づいているDRMのような何かをする必要がある場合、それはまったく別の状況です。

TLDR：ユーザーからの秘密を保持せず、ユーザーと共に秘密を保持します。

私が現在使用しているシステムの1つは、この方法で機能します。

• 認証サービスのログインフォームから始めます。2要素認証を使用して、自分が本人であることを確認します。
• 保護されたサービスにアクセスするために使用できる一時的なSSL証明書を受け取ります。サービスは、受け入れる証明書を追跡します。
• 私の交換は盗聴からこの証明書によって暗号化されます。有効期限が切れるため、クラックしようとすることはあまり役に立ちません。
• 証明書はすぐに（数時間で）期限切れになりますが、あまり速くないので、すべてのやり取りにパスワードを提供する必要はありません。
• 証明書は、反対側で即座に取り消すことができます。

もちろん、保護されたサービスは私の手の届かない場所で実行されます。マシン上で別のアカウント（および場合によってはコンテナ）で実行できますが、スーパーユーザー権限があり、制限を回避しようとすることができます。

基本的に、悪意のあるスーパーユーザーがいる場合、すべての賭けはオフです。また、脅威モデルに悪意のあるスーパーユーザーが存在すると想定する必要があります。

そのため、保護されたサービスをクライアントアクセス可能なマシンから分離する必要があります。保護されたサービスを、ネットワーク経由でのみアクセス可能なマシンに移動します。クライアントを仮想マシンに配置して、保護されたサービスが実行されている物理マシンの残りの部分にクライアントが届かないようにします。

保護されたサービスがそのような手段を命令できるほど貴重ではない場合、OSが提供する暗号化されたキーストアを使用してください：Windows、Linux、およびOSXの両方にキーリング実装があります。

私の考えでは、これを完全に安全に保つ唯一の方法は、ロック解除するパスフレーズでキー/パスワードを暗号化することです。このように、パスフレーズは、シークレットの開始または使用ごとに指定する必要があります。あまり便利ではありません。

別の方法は、セキュリティシステムをデータベースアカウントにすることです。あまりスケーラブルではありません...

システムの各ユーザーが独自のDBアカウントを持ち、それらのアカウントが事前に作成されているため、ユーザーに代わってアプリケーションがDBにアカウントを作成する権限を持っていない場合でも、かなり近づきます。良い解決策でもないので、設定ファイルの読み取りアクセスを非常に制限し、スーパーユーザーを信頼する必要があると思います。