暗号化されたPKCS12をHttps経由で送信する場合、どのようなリスクが存在しますか

Question

私が管理する発行者によって生成されたクライアント証明書の展開を自動化したいシナリオがあります。私が検討しているアプローチを以下に示します。関連するリスク（またはこれが必要以上に複雑な場合）についてフィードバックをいただければ幸いです。説明されている通信は、HTTPSを介したSOAPスタイルWCFです。

登録キーはサーバーで生成されます。
登録キーは、登録を実行する人と帯域外で共有されます。
ユーザーは登録キーを使用して登録を開始します。
クライアントシステムの登録により、メモリ内のキーペアが作成されます
クライアントシステムは、メモリ内キーペアの公開キーと登録コードを含む登録情報を送信します。
サーバーは登録コードを検証し、クライアント証明書と対応する秘密鍵、およびメモリ内PKCS12を作成します。
サーバーはさらに、クライアントから提供された公開鍵でPKCS12を暗号化します。
クライアントはサーバーの応答を受信し、返された証明書データを復号化して、ローカルキーストアにインポートします。

Bruno · Accepted Answer

クライアントで最初のキーペア（この手順の後で破棄するように見える）を生成し、サーバーで別のキーペアを生成して証明書を生成する代わりに、次のことができます。

クライアントで単一のキーペアを生成し、
公開鍵を認証要求に変え、
登録情報をHTTPS経由で発行者サービスに送信します。
サービスに証明書を発行させて送り返す、
クライアントは証明書を秘密鍵に関連付けます。

これはすべて、たとえばブラウザ内で直接実行できますが、カスタムSOAPベースのクライアントなど、他のクライアントでも実行できます。それは秘密鍵がそれを保持することを意図したパーティーを決して出ないという利点を持っています：クライアントはコピーを保持しないために発行者サービスを信頼する必要さえありません。

HTTPS接続を信頼して、登録情報がこの特定の認証要求で実際に送信されたことを確認できれば、最初の検証メカニズムは問題ありません。

編集：

コメントに続いて、とにかくあなたの秘密鍵を発行サーバー上のエスクロー用に保持したくないようです。この場合、秘密鍵を送信するリスクを負う意味はまったくありません。サーバーで証明書のキーペアを生成しても何も得られません。どちらかと言えば、リスクが高まっています（とにかくHTTPS経由で秘密キーを送信しているという事実によって制限されます）。

証明書を発行するとき、本当に重要なのは、発行者が証明書を作成するときにそのバインディングのアサーションに署名するため）。

本当に確認したいのは、証明書に使用される公開キーと、帯域外で共有される登録キーが同じ人物に属していることです。その観点から、彼らがあなたの公開鍵を提供する場合、またはあなたがそれを生成し、それを（秘密鍵で）提供する場合も同じです。このスキームでは、何らかの方法で秘密鍵を送信する必要はありません。

必要なのは、要求/アプリケーションから公開鍵を取得し（ユーザーが証明書を要求/適用するという意味で）、適切な登録シークレットが付属していることを確認し、証明書を発行することだけです。この公開鍵はCSRから、または必要に応じてプレーンな公開鍵として取得できます。（申請者がCSRに入力した内容の詳細はほとんど関係がありません。優れたCAはそれを破棄し、とにかく帯域外で確認したものだけを証明書に入れます。）

クライアントがサーバーへのHTTPS接続が適切に構成されていることを確認した場合：強力な暗号スイート、 TLS圧縮をオフにする、適切な証明書の確認、秘密の登録情報と公開されていることを保証する必要がありますキーが一緒になりました。

gowenfawr · Answer

これは受け入れられている方法です。たとえば、SecureWorksは、登録プロセス後にSSLを介してクライアント証明書を発行します。リスクプロファイルは主に次のとおりです。

意図した当事者以外の誰かが登録を実行できないようにします。これは他の登録プロセスと共通であり、対処する最大のリスクになる可能性があります。
HTTPSを介したキーの転送は特に危険ではありません。
キーを取得したら、ユーザーがキーを正しく処理することを信頼します。どのようにしてそれらの鍵を取得しても、これについてできることは何もありません。
クライアント側のクライアントキーを確実に保護します。エスクローして、再ダウンロードできるようにしますか？または、クライアントがそれらを入手したらすぐに消去し、必要に応じて将来新しいものを生成しますか？従来の「クライアントでキーを生成する」設定は、他のシステムがそれらを知っていた場合にキーを忘れる能力に対する根拠のない不信に大きく関係しています。

Thomas Pornin · Answer

手順は問題ないように見えますが、手順4で生成された非対称キーを使用してPKCS＃12ファイルを暗号化するための形式を決定する必要があります。これは見た目ほど簡単ではなく、標準形式を使用することをお勧めします。

その時点で、PKCS＃12には対称暗号化を行う固有の機能があり、通常は「パスワード」を使用しますが、パスワードは長くランダムにすることができます。「登録キー」をパスワードとして使用してPKCS＃12ファイルを暗号化すると、手順を簡略化できます。これにより、クライアント側でインメモリキーペアを生成する必要がなくなります。

実際、クライアントによって生成されたメモリ内のキーペアは、登録コードとともにHTTPSトンネルで送信されることによってのみ認証されるため、HTTPSが十分なセキュリティを提供し、攻撃者が自分のキーペアを代用するのを防ぐとすでに想定しています。その時点で。そのロジックの最後まで行って、単にHTTPSトンネルを信頼することもできます。証明書と秘密鍵をそのまま送信してください。それらをPKCS＃12ファイルとしてパックし、登録コードで暗号化すると（そのコードも十分に秘密であると想定されているため）、統合が容易になる場合があります（たとえば、ユーザーがPKCS＃12をファイルとして取得し、それを自分のOSにインポートする場合があります）「手動」）。