製品でのSSL証明書の取り扱い

Question

お客様の現場に搭載される製品（デバイス・システム）の開発を行っています。多くのお客様はセキュリティを心配する必要があり、セキュリティについて真剣に検討する必要があります。

当社の製品はHTTPS経由のAPIを提供します。これは、組み込みのUIで使用され、お客様も使用できます。

工場を出るときに製品にインストールされているSSL証明書の処理方法に関する情報とアドバイスを探しています。

何か入力をいただければ幸いです。見落としや見落としはありますか？

今日の現状

現在（システムは開発中）、すべての開発ユニットとプロトタイプユニットに同じ自己署名証明書をインストールしています。これには明らかに信頼の連鎖がなく、ユーザーには警告が表示されます。

これは他のメーカー（Cisco、Ubiquitiなど）が採用しているアプローチと同じだと思いますが、確認していただければ幸いです。

オプション

お客様は独自の証明書を提供できます、希望する方法で署名します（パブリックまたはプライベート）。これは彼らに信頼の連鎖を与え、彼らが彼らが本当に* that *システムに接続していることを確認できるようにします。
各ユニットに異なる自己署名証明書をインストールする。証明書がまだ信頼されていないため、すべてのユニット間で単一の自己署名証明書を共有するよりも、これを行うメリットがあるかどうかはわかりません。
各ユニットに公的に署名された証明書をインストールする工場から出荷されます。私の知る限り、これは機能しません。証明書はFQDN（おそらくワイルドカードを使用）に関連付けられているため、顧客の証明書を生成して署名する方法はありません。

Kirill Sinitski · Accepted Answer

すべての開発ユニットとプロトタイプユニットに同じ自己署名証明書をインストールしています。

すべてのユニットに同じ証明書をインストールすることは、証明書を処理するときに想像できる最悪のセキュリティ対策です。これで、ハードコードされたデフォルトの管理資格情報を使用して製品をリリースしないようになりました。デフォルトの資格情報は一度抽出され、それを実装するすべてのデバイスのセキュリティ侵害に使用される可能性があるため、デフォルトの資格情報は使用しません。これは非常によく似た状況です。デフォルトの証明書は、秘密鍵が1回抽出され、この証明書に依存するすべてのデバイスを侵害するために使用される可能性があることを意味します。

暗号的には、自己署名証明書と信頼できるサードパーティ証明書の両方が同じように動作します。各証明書は、秘密の秘密鍵と非秘密の公開鍵で構成される鍵ペアに関連付けられています。秘密鍵がわかっている場合は、公開鍵と証明書に関連付けられているすべてのアクションを実行できます。

デフォルトの証明書の侵害は、単に認証を危うくする以上の意味を持っています。 TLSの場合、使用される暗号によっては、証明書が共有秘密の確立に使用される可能性があります。このような場合、最初のハンドシェイクを見た後、パッシブ盗聴者がTLSトラフィックを復号化できます。

確かに、有能な管理者は独自の証明書をアップロードすることでこの問題を修正しますが、デフォルトの証明書を信頼することで、実際に何人が「動作させるだけ」の段階で停止しますか？代わりに、最初の起動時または工場出荷時のリセット時に新しいキーペアを生成する必要があります。これが、安全なネットワークデバイスの動作方法です。新しい証明書を生成するときは、システムで利用可能なエントロピーが十分にあり、因数分解可能な鍵が生成されないことを確認する必要もあります。

Kevin · Answer

顧客は、自分の証明書を提供し、希望する方法で（公的または私的に）署名することができます。これは彼らに信頼の連鎖を与え、彼らが本当にthatシステムに接続していることを彼らが確信できるようにします。

これは、[〜＃〜] a [〜＃〜]）のいずれかが、一般に公開されている「実際の」ドメイン名を持つことを示唆しています。インターネット（イントラネットドメイン名やプライベートIPアドレスではなく）または[〜＃〜] b [〜＃〜]）典型的な顧客は独自の内部認証局を運用するために必要な技術知識。

（A）がtrueの場合、製品は Let's Encrypt にダイヤルアウトし、署名された証明書をその方法で取得できます。これには、サービスに「実際の」ドメイン名があり、公共のインターネットから完全に見えることが必要です（つまり、ポート80や443でファイアウォールが設定されていない）。 Let's Encrypt証明書は、完全に自動化された方法で取得でき、FQDNを理解して制御している（Webトラフィックを処理できる）場合、手動の手順は必要ありません。当然、サービスは合理的に「丁寧」な方法で操作する必要があります。特に、サービスが無料であることを考慮してください（一度に大量のリクエストを送信したり、指数再試行バックオフを実装したりしないでください）。

（B）がtrueの場合は、説明するオプション（つまり、顧客に証明書を提供させる）を必ず使用する必要があります。なぜなら、顧客はあなたよりもこの問題を解決する立場にあるからです。ただし、ほとんどの業界では、（B）は当てはまりません。それでも、十分に冒険的な顧客はこれを行うオプションを望んでいる可能性があるので、とにかくそれを提供する必要があります。

（A）も（B）も当てはまらない場合は、他の回答のいずれかに従う必要があります。この場合、一般的な顧客は適切な証明書を提供することができないため、顧客に責任を持たせないでください。カスタム証明書を使用するためのオプションを提供することもできますが、それをデフォルトにしないでください。

David A · Answer

あなたはユニークな証明書を提供するような何かをすることができます

product-serial-number.product-name.company-name.com

認定パスで信頼されているものから発行されている。証明書はその目的のためにまだ信頼されていませんが、誰かがボックス上のステッカーと照合して証明書をチェックできます（オプションで証明書を証明書ストアにインストールできます）。残念ながら、ChromeおよびEdgeでは、HTTPSページで証明書の詳細を簡単に表示できなくなっているため、これは困難です。

Trevor · Answer

私はまったく同じ状況にあり、コンシューマーデバイスに埋め込まれたHTTPSサーバー（および関連コンテンツREST APIなど））の開発を担当していました。

質問ですでに述べたように、CA（認証局）署名付き証明書のインストールは、証明書をドメインに関連付ける必要があるため、残念ながらオプションではありません。

私の経験では、各デバイスで一意のキーペアと証明書を生成することが最善の方法です。私のデバイスでは、これはファームウェアがデバイスにロードされた後の最初の起動時に、また出荷時設定にリセットされた場合に行われます。使用中のマイクロコントローラには、この目的で使用されるハードウェアRNGがあります。

すべてのデバイスで同じキーペアと証明書を使用することは、攻撃者がデバイスの1つを取得して秘密キーを抽出するだけで、すべてのデバイスが危険にさらされる可能性があると考えると、特に危険です。

したがって、私の経験では、（理想的な解決策は存在しないように思われるため）実際に実行できる最善の方法は、製品マニュアルの自己署名証明書に関するブラウザのセキュリティ警告を確認する必要がある理由を顧客に通知することです。各デバイスが独自の一意の秘密鍵と証明書を作成することを少なくとも確認してください。