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 年 5 月に行われます。
Device Update エージェントのバージョン 1.1.0 以降では、エージェントは、そのデバイスへの更新プログラムの展開が行われるたびに、ルート キーに対する変更を自動的にチェックします。 考えられる変更:
- 新しいルート キーを使用できます。
- 既存のルート キーが無効 (実質的に "取り消されました") です。つまり、信頼を確立するために有効ではなくなりました。
上記のいずれかまたは両方に該当する場合、Device Update エージェントは DU サービスから新しい ルート キー パッケージを自動的にダウンロードします。 このパッケージには、すべてのルート キーの完全なセットと 、無効になったルート キーや署名キーに関する情報を含む無効なリスト が含まれています。 ルート キー パッケージ自体は各ルート キーで署名されているため、DU エージェント自体の一部である元のルート キーと、その後ダウンロードされたルート キーの両方からパッケージの信頼を確立できます。 検証プロセスが完了すると、新しいルート キーは、特定の更新マニフェストの署名キーを使用して信頼を検証する目的で信頼されていると見なされますが、無効な一覧に記載されているルート キーまたは署名キーは、その目的で信頼されなくなります。
シグネチャ
すべての署名には、ルート鍵の 1 つによって署名された署名 (公開) キーが伴います。 署名は、署名キーに署名するために使用されたルート キーを識別します。
Device Update エージェントでは、署名 (公開) キーの署名が正しいこと、有効であること、また承認されたルート キーのいずれかによって署名されていることを最初に検証することによって、署名を検証する必要があります。 署名キーが問題なく検証されたら、その時点で信頼されている署名公開キーを使用して、署名自体を検証することができます。
署名キーはルート キーよりもずっと短い間隔でローテーションされるため、さまざまな署名キーによって署名されたメッセージを想定してください。
署名キーの失効は Device Update サービスによって管理されるため、ユーザー側で署名キーをキャッシュしようとしないでください。 署名を伴った署名キーを常に使用してください。
デバイスのセキュリティ保護
Device Update に関連したセキュリティ資産が、デバイス上で適切にセキュリティで保護されるのを保証するのは重要なことです。 ルート キーなどの資産は、変更されないよう保護する必要があります。 ルート キーを保護するには、セキュリティ デバイス (TPM、SGX、HSM、その他のセキュリティ デバイス) を使用する方法や、参照実装で現在行われているように Device Update エージェントでハードコーディングするなど、さまざまな方法があります。 後者の場合、Device Update エージェントのコードを悪意ある変更から保護するために、エージェントのコードをデジタル署名し、システムのコード整合性サポートを有効にする必要があります。
コンポーネントからコンポーネントへのハンドオフが安全な方法で実行されることの保証など、他のセキュリティ対策が必要になる場合があります。 例えば、様々なコンポーネントを実行するために特定の分離されたアカウントを登録したり、ネットワークベースの通信 (REST API 呼び出しなど) を localhost のみに制限したりすることが挙げられます。