ファームウェアのドメイン内で侵害された秘密鍵を処理するための最良の戦略は何ですか？
更新の整合性と権限を保証するために非対称暗号を使用するファームウェアプロジェクトがあります。秘密鍵は社内に保存され、公開鍵はファームウェアにあり、更新の試みの完全性と信頼性を検証します。
現在、署名の検証に使用される公開キーは、工場出荷時の更新時にのみ（NVデータで）「書き込まれる」ため、お客様は独自のキーを追加してFWを上書きすることはできません。
秘密鍵が危険にさらされた場合に対処するための戦略を実装したいと思います。参照する規格または同様の文書はありますか？
一部のコンテキスト：ファームウェアを搭載したユニットはインターネットにアクセスできません。侵害された秘密鍵は、関連する公開鍵を現場で手動で置き換える必要があります。
ファームウェアに複数の公開鍵を置き、対応する秘密鍵をさまざまな場所に保存します。更新が1つのキーだけでなく、allの秘密キーで署名されていることを要求します。コード署名のためであっても、秘密キーを一緒にしないでください。代わりに、秘密キーが格納されている場所の間でコードを移動して、それぞれが順番にコードに署名できるようにします。そうすれば、1つの秘密鍵が侵害されても影響はありません。
「お客様が独自のファームウェアをインストールできないようにするにはどうすればよいですか」という質問を想定すると、この問題に関する業界標準は（簡単に言えば）次のようになります。
- キーで署名されたファームウェアでの起動のみを許可する安全なブートローダーを使用してください。
- 安全なストレージ（ヒューズまたはOTP（ワンタイムプログラミング）とも呼ばれます）を使用してこのキーを保存し、物理的に変更できるようにしますできない。 [〜＃〜]または[〜＃〜]
- 暗号化ジョブを実行してキーを抽象化するOracleチップセットを使用します。
さらに、デバイスがハードウェア攻撃に対して安全であることを確認する必要もあります（フラッシュデバイスの変更などafter署名が確認されました）
問題は、デバイスがmustの準備がすべて整っていることです。これは、プロジェクトの最初に設計する必要があるセキュリティの一種であり、後で追加することは非常に困難です。どのようなハードウェアをお持ちですか？ TEEまたはSEEメカニズムを実装していますか？そうでない場合は、これを実装するためにハードウェアに組み込むことができるコンパニオンチップがあります...とにかく、本当のポイントは秘密キーです。秘密鍵が漏洩した場合、セキュリティ全体が破壊されます。
通常（およびその種の秘密を管理する会社での私の経験に基づいて）、公開鍵は、工場での生産中にハードウェアの製造元によってデバイスに焼き付けられ、ファームウェアを開発している会社にも知らされていません。開発を容易にするために、通常は2組のキーがあります。本番用キーは、秘密にしておくことが最もよく、本番デバイスでのみ使用され、開発者用のデバイスに焼き付けられる開発キーです。通常、この「開発デバイス」では、最も重要な機能を実行できません。
さらに進むには、OTP、SEE、TEE、Key Ladderなどを検索します。