証明書を外部メモリに保持することは悪い習慣ですか？

STM32マイクロコントローラーを使用してAWS-IoTに取り組んでいます。

今日まで、証明書をフラッシュに書き込み、フラッシュを外部読み取りからロックしていました。アプリケーションコードが増えると、フラッシュ上のスペースが少なくなるため、証明書を外部でSDカード/ EEPROMに移動し、AWS-IoTに接続する前に必要なときにいつでも読み取ることを計画していました。

ノート：

• Thing用に作成されたポリシーは、特定の名前のデバイスのみがその特定の証明書に接続することを許可します。

• データプロセッサに接続されている2つのチャネル（名前とデータフィードチャネル）のみにパブリッシュすることが許可されています。

• Thingが他のトピックをパブリッシュ/サブスクライブすると、AWSはThingを即座に切断します。

デバイスの盗難/不正が検出された場合は、サーバーからキーを無効にします。

悪用者は証明書（RootCA、サーバーキー、クライアントキー）で何ができますか？

悪用者がアクセスできる外部ストレージにそのようなユースケースの証明書を保持することは悪い習慣ですか？

あなたは「証明書」について言及しますが、文脈から、私は2つの異なることを言及していると思います。

• デバイスには、このデバイスに固有であり、デバイスの外部では知られていない秘密鍵があります。このキーはデバイスを識別します。そのキーにアクセスできる人はだれでもデバイスを偽装できます。つまり、次のことが可能になります。

  • デバイスが発行することを合法的に許可されているチャネルで、有効であるが正しくないデータを発行します。
  • 正当なデバイスを禁止する無効なデータを公開します。
  • おそらく、ユースケースに応じて、デバイスの所有者のいくつかの個人情報を公開します。

  この秘密鍵は秘密にしておくべきです。

• デバイスにはおそらく少なくとも1つの公開鍵があり、これにより、どのサーバーと通信しているかを認識できます。誰かがこのキーを読むことができても大丈夫です。それは公開されています。ただし、攻撃者はキーを変更できません。それ以外の場合は、デバイスと通信してサーバーを偽装する可能性があります。これにより、次のようなことが可能になります。

  • ファームウェア更新をデバイスにプッシュします。
  • 構成の更新をデバイスにプッシュします。
  • デバイスにデータを別の場所にアップロードさせます。

良いニュースは、この脅威分析は実際にはあまり関連性がないということです。セキュリティを犠牲にする必要はありません。（少なくとも機密性と信頼性のプロパティではありません。外部にデータを保存すると、システムの一部が失われる可能性があるため、可用性が低下します。）

128ビット以上のストレージに少なくとも1回は書き込むことができ、それ以上であれば、安全なリモートストレージソリューションを実装できます。限られたスペースのデバイスストレージを使用して秘密鍵を保存します。この秘密鍵はデバイスごとに一意である必要があります。STM32にはハードウェアRNGがあるため、初回起動時にデバイス上で生成できます。デバイスにハードウェアRNGがない場合は、安全なデバイス外の場所でキーを生成し、デバイスに注入できます。

このキーを使用して、デバイスに保管するものに認証された暗号化を使用します。外部ストレージから一部のデータを読み取りたい場合は、データをロードし、復号化して検証します。一部のデータを外部ストレージに書き込む場合は、暗号化して署名します。これにより、データが内部ストレージのデータと同じくらい機密性と信頼性が保証されます。

認証された暗号化は、機密性と保証するのに十分である信憑データのを、それはかなりその保証するものではありません整合性を。

• データのチャンクが複数ある場合、デバイスがデータのチャンクを読み戻すときに、これが正しいチャンクであるかどうかを確認できません。解決策：（例の一つで、各チャンクを開始し、各チャンクのコンテンツ内で一意の識別子が含まれ"AWS-IoT private key."、"configuration CA certificate."、"publishing server CA certificate."、"user personal data."、...）。
• ある時点でデータを更新した場合、それを読み返すと、そのデータの最新バージョンを取得していることを確認できません。誰かが外部ストレージを変更できる場合、真正性チェックに失敗するため、偽のデータを置くことはできませんが、以前は本物であったものがまだ本物であるため、古いデータを復元できます。解決策：外部に保存されている各データチャンクに、そのチャンクの新しいバージョンを書き込むたびにインクリメントするカウンターを含めます。チャンクを読み戻したら、それが予期されたバージョンであることを確認してください。

外部ストレージが損傷したり紛失したりした場合にデバイスが壊れないようにするには、内部ストレージのスペースが限られている限られたスペースで、デバイスを「良好」な状態にリセットするために必要なものをすべて優先する必要があります。 。2番目の優先事項は、パフォーマンスの考慮事項です。

少しコンテキスト

AWS IoTでMQTT を使用しているため、認証とセキュリティにX.509証明書を使用することが期待されています。Amazonには、証明書を保護する方法についてのガイダンスが少しあるので、ここで引用します。

証明書を使用すると、非対称鍵をデバイスで使用できます。つまり、機密性の高い暗号化マテリアルがデバイスから出ることを許可せずに、秘密キーをデバイスの安全なストレージに書き込むことができます。

現在STM32の読み出し保護（RDP）を使用しているため、最も決定的な攻撃者以外のすべての攻撃者は、現在のスキームで証明書にアクセスできなくなります。

グローバルな読み出し保護により、組み込みのファームウェアコード（フラッシュメモリにプリロードされている）は、リバースエンジニアリング、デバッグツールを使用したダンプ、またはその他の侵入攻撃の手段から保護できます。

• レベル0-保護なし（デフォルト）
• レベル1-フラッシュメモリは、RAMロードされたコードによるデバッグまたはコードダンプによる読み取りから保護されます。
• レベル2-すべてのデバッグ機能が無効になります

外部ストレージは安全ですか？

それはおそらくないとして、セキュア。クライアントの秘密鍵が盗まれた場合、攻撃者はデバイスから送信されたように見えるデータを送信しますが、実際にはそうではありません。送信するデータは明確ではありませんが、信頼できないデータはセキュリティリスクになる可能性があります。

非公開にするにはどのビットが必要ですか？

AWS IoTでデバイス証明書を作成すると、次のような画像が表示されます。

^{AWS IoTドキュメントの「デバイス証明書の作成とアクティブ化」ページの画像。}

秘密鍵は、あなたが本当に保持する必要があるものです... プライベート、そして可能であれば、確実に読み取り保護されたメモリに保存する必要があります。公開鍵と証明書は共有されるように設計されているため、スペースが足りなくなった場合は、それらを安全に外部ストレージに移動できます。ページでもう少しコンテキストを取得できますSSL / TLSはどのように機能しますか？Information Security Stack ExchangeとWikipediaの公開鍵暗号法で。秘密鍵を秘密にする必要がある理由を説明するためにこの画像を含めなかったとしたら、私はあなたに害を及ぼすでしょう。

。

^{パブリックドメインにリリースされたWikipediaの画像。}

デバイスの公開キーは、AW​​S IoTがデバイスに送信するメッセージに署名するために使用するものです（ただし、誰がメッセージを送信しているかは証明しません）。ですから、公開鍵を盗んだとしても、それが秘密であることを意図しているわけではないので、それは大きな災害ではありません。

秘密鍵は、攻撃者がこれを盗む場合、それは少し大きな問題がありますので、お使いのデバイスの用途は、メッセージを復号化するものです。

また、攻撃者がRootCA証明書を盗んだ場合にどうなるかについても質問しました。誰かがAWS IoTの秘密鍵を盗んだ場合、それは悲惨なことになりますが、デバイスのRootCA証明書はそれではありません。RootCA.crtAmazonはあなたを与えることで、完全にパブリック、および目的は、あなたがどのような方法（AWSのIoTのサーバーである可能性が最も高いのman-in-the-middleふり）に攻撃されていないことを確認できるようにということです。

ハッキングされたデバイスはどのような損害を与える可能性がありますか？

盗まれたデバイスは、ポリシーに記載されているアクションのみを実行できます。最小特権の原則に従うようにしてください。絶対に必要な特権だけをデバイスに付与するので、最悪の事態が発生した場合でも、大混乱をもたらすことはできません。あなたの特定のケースについて：

データプロセッサに接続されている2つのチャネル（名前とデータフィードチャネル）のみにパブリッシュすることが許可されています。

それは良い。すべての攻撃は、デバイスが公開できる2つのMQTTトピックのみに分離される必要があるため、大規模な害を引き起こしません。

理想的には、システム全体ではなく、単一のユニットを分解することでそのユニットのみが破壊されるような設計をシステム全体に持たせたいと考えています。

特に、キーをチップ間の標準の電気的インターフェースを通過するように別個のメモリに格納している場合、それらは、公開しても安全な、またはデバイスの特定の物理インスタンスに固有のキーでなければなりません。

個々のキーが単一のデバイスから抽出され、不正使用されたり、複数の無許可のクローンからのトラフィック量で表示されたりする場合は、サーバー側でそのキーを禁止できます。

もちろん、キーは、権限のない当事者がいくつかの抽出された例から推測したり、独自の互換性のある独自のインスタンスを生成したりすることができない性質を持つ必要があります。つまり、有効なものがある場所で生成したキーの記録が必要です。可能性のある巨大な空間のほんのわずかで予測不可能な部分、または生成したキーに署名して、システムにその署名の証明と組み合わせたキーのみを受け入れるようにする必要があります。

クライアントのキーは秘密にしておく必要があります（ただし、他の回答で説明されているように、キーを失うことの意味を理解してください）。サーバーの公開キーとAWSの公開証明書は、秘密にしておくためではなく、AWS証明書を（侵害されたデバイス上で）置き換えることにより、攻撃者がデバイスを実行するように仕向けることができるため、デバイス側で保護することが重要です攻撃者のホス​​トとのやり取り、またはAWSへの通信の中間者への交換。

これを実行することにより（2）、攻撃者はTLSセキュリティを取り除くことができ、クライアントキーをリバースエンジニアリングできるほどセキュリティが十分に低下する可能性があります。

この推論により、外部メモリデバイスに公開しても安全な唯一のキーは、サーバーの公開キーです。これ（3）を変更すると、アクセスを設計するのが難しいと思われる不正なAWSサービスにデバイスが強制的に接続されるようになります。このキーだけを漏らしても、誰かが一部の送信を盗聴したり偽造したりできる可能性があります（たとえば、TLSレイヤーを何らかの方法でダウングレードできる場合）。

したがって、要約すると、リスクは単に情報を漏洩することではなく、（信頼されていると思われる）ファームウェアに信頼できない安全な情報を提供できる場合にリスクがあります。