Device Update のセキュリティ モデル
Device Update for IoT Hub により、デバイスのファームウェア、イメージ、アプリケーションの更新を IoT デバイスにデプロイする安全な方法が提供されます。 このワークフローで提供される、エンドツーエンドのセキュリティで保護されたチャネルは、完全な Chain of Custody (CoC) モデルを備えており、デバイスではこのモデルを使用して、更新が信頼できること、変更されていないこと、意図的であることを証明できます。
Device Update ワークフローの各ステップは、さまざまなセキュリティ機能およびプロセスによって保護されており、パイプラインの各ステップで次への安全なハンドオフが確実に実行されるようになっています。 Device Update エージェントの参照コードは、不正な更新要求を識別し、適切に管理します。 また、参照エージェントは、すべてのダウンロードをチェックし、コンテンツが信頼できること、変更されていないこと、意図的であることを保証します。
まとめ
Device Update インスタンスに更新がインポートされると、サービスでは更新バイナリ ファイルをアップロードおよびチェックして、それらが悪意のあるユーザーによって変更されていないことを確認します。 検証されると、Device Update サービスにより、インポート マニフェストからのファイル ハッシュやその他のメタデータを使用して、内部的な更新マニフェストが生成されます。 Device Update サービスでは、この更新マニフェストに署名します。
サービスにインポートされ、Azure に格納されると、Azure Storage サービスでは、更新バイナリ ファイルとそれに関連付けられた顧客メタデータを保存時に自動的に暗号化します。 デバイス更新サービスでは、追加の暗号化は自動的に提供されませんが、コンテンツがデバイス更新サービスに到達する前に、開発者が自分でコンテンツを暗号化できます。
Device Update サービスからデバイスに更新がデプロイされると、署名されたメッセージが、保護された IoT Hub チャンネルを介してデバイスに送信されます。 Device Update エージェントでは署名を検証して、それが認証されているかどうかを判定します。
結果として生成されるバイナリ ダウンロードは、更新マニフェスト署名の検証を通じてセキュリティで保護されます。 更新マニフェストにはバイナリ ファイルのハッシュが含まれているため、マニフェストがいったん信頼されれば、Device Update エージェントはそのハッシュを信頼してバイナリと照合します。 更新バイナリは、ダウンロードされ、検証された後、デバイス上のインストーラーに渡されます。
実装の詳細
単純でパフォーマンスの低いデバイスにも Device Update サービスがスケールダウンすることを保証するために、セキュリティ モデルでは、未加工の非対称キーと未加工の署名を使用しています。 JSON Web Token や JSON Web Key などの JSON ベースの形式を使用します。
更新マニフェストによる更新コンテンツのセキュリティ保護
更新マニフェストは 2 つの署名を使用して検証されます。 これらの署名は、署名キーとルート キーで構成される構造体を使用して作成されます。
Device Update エージェントには、すべての Device Update 互換デバイスに使用される埋め込みの公開キーが含まれています。 これらの公開鍵は、ルートキーです。 対応する秘密キーは Microsoft によって制御されます。
Device Update Agent に含まれていない、またはデバイスに保存されていない公開/秘密キー ペアも Microsoft によって生成されます。 これは署名キーです。
Device Update for IoT Hub に更新がインポートされ、サービスによって更新マニフェストが生成されると、サービスでは署名キーを使用してマニフェストに署名し、その (ルート キーによって署名される) 署名キー自体を含めます。 更新マニフェストがデバイスに送信されると、Device Update エージェントは次の署名データを受信します。
- 署名値そのもの。
- #1 の生成に使用されるアルゴリズム。
- #1 の生成に使用される署名キーの公開キー情報。
- #3 内の公開署名キーの署名。
- #3 の生成に使用されるルート キーの公開キー ID。
- #4 の生成に使用されるアルゴリズム。
Device Update エージェントでは、その情報を使用して、公開署名キーの署名がルート キーによって署名されていることを検証します。 Device Update エージェントでは次に、更新マニフェストの署名が署名キーによって署名されていることを検証します。 すべての署名が正しい場合、その更新マニフェストは Device Update エージェントによって信頼されます。 更新マニフェストには更新ファイル自体に対応するファイル ハッシュが含まれているため、ハッシュが一致するのであれば更新ファイルも信頼できます。
ルートおよび署名キーがあるため、Microsoft は署名キーを定期的にロールでき、これはセキュリティのベスト プラクティスです。
JSON Web Signature (JWS)
updateManifestSignature は、updateManifest 内に含まれている情報が変更されていないことを確認するために使用されます。
updateManifestSignature は、JSON Web Key を備えた JSON Web Signature を使用して生成されるため、ソースの検証が可能になっています。 署名は Base64Url エンコード文字列であり、"." で区切られた 3 つのセクションがあります。 JSON キーおよびトークンの解析と検証については、jws_util.h のヘルパー メソッドを参照してください。
JSON Web Signature は、JSON ベースのデータ構造を使用してコンテンツに署名するために広く使用されている、提案済みの IETF 標準です。 これは、データの署名を検証することによってデータの整合性を保証する方法です。 詳細については、JSON Web Signature (JWS) RFC 7515 を参照してください。
JSON Web Token
JSON Web Token は、2 者間でクレームを安全に表現するためのオープンな業界標準の方法です。
ルート キー
すべての Device Update デバイスには、ルート キーのセットが含まれている必要があります。 これらのキーは、Device Update のすべての署名の信頼のルートです。 いかなる署名も、正当と見なされるためには、これらのルート キーのいずれかを通じてチェーンに加わっている必要があります。
セキュリティ上の理由から、定期的に署名キーをローテーションすることが適切であるため、ルート キーのセットは時間の経過と共に変化します。 その結果、Device Update エージェント ソフトウェアは、Device Update チームによって指定された間隔でルート キーの最新のセットによって更新する必要があります。 次の計画的なルート キーのローテーションは 2025 年 8 月に行われます。
Device Update エージェントのバージョン 1.1.0 以降では、そのデバイスへの更新のデプロイが発生するたびに、エージェントではルート キーの変更がないかどうかを自動的にチェックします。 可能性のある変更として、次のものがあります。
- 新しいルート キーが使用可能になった。
- 既存のルート キーが無効になった (実質的に "失効した")。つまり、信頼を確立するために有効でなくなった。
このどちらかまたは両方に該当する場合、Device Update エージェントでは、DU サービスから新しい "ルート キー パッケージ" を自動的にダウンロードします。 このパッケージには、すべてのルート キーの完全なセットと、どのルート キーまたは署名キー、あるいはその両方が有効でなくなったかに関する情報を含む "無効になった一覧" が含まれています。 ルート キー パッケージは、そのパッケージの信頼を DU エージェント自体の一部である元のルート キーと、それ以降にダウンロードされた任意のルート キーの両方から確立できるように、それ自体が各ルート キーによって署名されています。 検証プロセスが完了すると、すべての新しいルート キーが特定の更新マニフェストの署名キーとの信頼を検証するために信頼できると見なされるに対して、無効になった一覧に示されているルート キーまたは署名キーはすべて、その目的のために信頼できなくなります。
シグネチャ
いずれかのルート キーによって署名された署名 (公開) キーは、すべての署名に付随します。 署名は、署名キーに署名するために使用されたルート キーを識別します。
Device Update エージェントでは、署名 (公開) キーの署名が正しいこと、有効であること、また承認されたルート キーのいずれかによって署名されていることを最初に検証することによって、署名を検証する必要があります。 署名キーが問題なく検証されたら、その時点で信頼されている署名公開キーを使用して、署名自体を検証することができます。
署名キーは、ルート キーより早いペースでローテーションされるため、さまざまな署名キーによって署名されたメッセージを予測してください。
Device Update サービスでは、必要に応じて署名キーの失効を管理するため、ユーザーが署名キーをキャッシュしようとしてはいけません。 署名を伴った署名キーを常に使用してください。
デバイスのセキュリティ保護
Device Update に関連したセキュリティ資産が、デバイス上で適切にセキュリティで保護されるのを保証するのは重要なことです。 ルート キーなどの資産は、変更されないよう保護する必要があります。 ルート キーを保護するには、セキュリティ デバイス (TPM、SGX、HSM、その他のセキュリティ デバイス) を使用する方法や、参照実装で現在行われているように Device Update エージェントでハードコーディングするなど、さまざまな方法があります。 後者の場合は、Device Update エージェント コードの悪意のある変更から保護するために、エージェント コードのデジタル署名と、システムのコード整合性のサポートの有効化が必要になります。
コンポーネントからコンポーネントへのハンドオフが安全な方法で実行されることの保証など、他のセキュリティ対策が必要になる場合があります。 例えば、様々なコンポーネントを実行するために特定の分離されたアカウントを登録したり、ネットワークベースの通信 (REST API 呼び出しなど) を localhost のみに制限したりすることが挙げられます。