次の方法で共有

X.509 証明書の構成証明

  • [アーティクル]

この記事では、Device Provisioning Service (DPS) の X.509 証明書の構成証明を使用してデバイスをプロビジョニングするときに関係する概念について説明します。 この記事は、デプロイのために準備されたデバイスの取得に関わるすべてのユーザーに最も役立ちます。

X.509 証明書は、ハードウェア セキュリティ モジュール HSM に格納できます。

ヒント

運用環境のデバイスに、X.509 証明書などのシークレットを安全に格納するために、デバイスで HSM を使用することを強くお勧めします。

X.509 証明書チェーンについて

X.509 証明書を構成証明メカニズムとして使用することは、実稼働環境を拡張し、デバイスのプロビジョニングを簡素化するための優れた方法です。 X.509 証明書は通常、信頼する証明書チェーンに配置されます。証明書チェーンでは、チェーン内の各証明書が次の上位証明書の秘密キーによって署名され、最後は自己署名ルート証明書で終わります。 この配置により、信頼された証明機関 (CA) によって生成されたルート証明書から、各中間 CA 証明書を経由して、デバイスにインストールされた最後の証明書まで、委任された信頼チェーンが確立されます。 詳細については、「X.509 CA 証明書を使用したデバイス認証」をご覧ください。

証明書チェーンは、多くの場合、デバイスに関連付けられている論理的または物理的階層を表します。 たとえば、製造元は次の証明書階層を作成できます。

  • 自己署名ルート CA 証明書が証明書チェーンを開始します。
  • ルート証明書が、ファクトリごとに一意の中間 CA 証明書を生成します。
  • 各ファクトリの証明書は、ファクトリの生産ラインごとに一意の中間 CA 証明書を生成します。
  • 最後に生産ラインの証明書が、生産ラインで製造されるデバイスごとに一意のデバイス (エンドエンティティ) 証明書を生成します。

詳細については、「IoT 業界における X.509 CA 証明書の概念理解」をご覧ください。

ルート証明書

ルート証明書は、証明機関 (CA) を表す自己署名の X.509 証明書です。 証明書チェーンの終端、つまりトラスト アンカーになります。 ルート証明書は組織が自ら発行することも、ルート証明機関から購入することもできます。 ルート証明書は、ルート CA 証明書とも呼ばれる場合があります。

中間証明機関の証明書

中間証明書は、ルート証明書 (または、証明書チェーン内のルート証明書を使用する別の中間証明書) によって署名された X.509 証明書であり、新しい証明書に署名することもできます。 チェーン内の最後の中間証明書は、リーフ証明書に署名します。 中間証明書は、中間 CA 証明書とも呼ばれます。

中間証明書は、さまざまな方法で使用されます。 たとえば中間証明書を使用して、製品ラインや顧客の購入デバイス、会社の部門、工場別にデバイスをグループ化できます。

Contoso という大企業が、ContosoRootCert という名前のルート証明書を使用している独自の公開キー基盤 (PKI) を持っていると仮定します。 Contoso の各子会社には、ContosoRootCert によって署名された独自の中間証明書があります。 各子会社では、中間証明書を使用して各デバイスのリーフ証明書に署名します。 このシナリオでは、Contoso は、ContosoRootCert が検証済み証明書である 1 つの DPS インスタンスを使用できます。 各子会社に対する登録グループを持つことができます。 この方法により、個々の子会社は証明書の検証について心配する必要がなくなります。

エンド エンティティ "リーフ" 証明書

リーフ証明書、つまりエンドエンティティ証明書は、証明書の所有者を識別します。 ルート証明書は、その証明書チェーンと 0 以上の中間証明書に含まれています。 リーフ証明書は、他の証明書の署名には使用されません。 プロビジョニング サービスに対してデバイスを一意に識別し、デバイス証明書と呼ばれることもあります。 デバイスは認証時に、自身の証明書に関連付けられた秘密キーを使用して、サービスからの所有証明チャレンジに応答します。

証明書の準備

デバイスでは、DPS 経由で IoT Hub に接続する際に、2 つの異なる種類の証明書が使用されます。 デバイスを準備する際は、接続する前に、すべての適切な証明書が作成され、デバイスに追加されていることを確認してください。

  • パブリック ルート証明書: すべてのデバイスには、IoT Hub、IoT Central、Device Provisioning Service が接続を認可するために使用する、パブリック ルート証明書のコピーが必要です。
  • 認証証明書: X.509 証明書は、デバイス ID を認証するためのおすすめの方法です。

必要なパブリック ルート証明書

Azure IoT デバイスは、TLS を使用して、接続先の IoT ハブまたは DPS エンドポイントの信頼性を検証します。 各デバイスには、IoT Hub と DPS で使用されるルート証明書のコピーが必要です。 すべてのデバイスで、信頼された証明書ストア内に次のルート CA を含めることをおすすめします。

  • DigiCert Global G2 ルート CA
  • Microsoft RSA ルート CA 2017

推奨される証明書のプラクティスについての詳細は、TLS サポートを参照してください。

X.509 証明書を使用した認証

プロビジョニング サービスでは、X.509 構成証明メカニズムによるデバイス アクセスの制御に使用できる 2 つの登録タイプが公開されています。

  • 個別登録エントリは、特定のデバイスに関連付けられたデバイス証明書を使用して構成されます。 これらのエントリは、特定のデバイスの登録を制御します。
  • 登録グループ エントリは、特定の中間 CA 証明書やルート CA 証明書に関連付けられます。 これらのエントリは、証明書チェーン内にその中間証明書やルート証明書を持つすべてのデバイスの登録を制御します。

1 つの証明書は、DPS インスタンス内の 1 つの登録エントリでのみ指定できます。

相互 TLS のサポート

X.509 構成証明用に DPS の登録が構成されている場合、DPS では相互 TLS (mTLS) がサポートされます。

DPS 暗号化アルゴリズムの要件

Device Provisioning Service は、暗号化に Rivest-Shamir-Adleman (RSA) アルゴリズムまたは Elliptic Curve Cryptography (ECC) アルゴリズムを使用する X.509 証明書のみを受け入れます。 ECC と RSA は同等のレベルの暗号化強度を提供しますが、ECC は、より短い長さのキーを使用します。

デバイス構成証明用の X.509 証明書を生成するために ECC メソッドを使用する場合は、次の Elliptic Curve をお勧めします。

  • nistP256
  • nistP384
  • nistP521

DPS 証明書の名前付けの要件

個別登録エントリで使用されるリーフ証明書では、サブジェクト共通名 (CN) が登録 ID に設定されている必要があります。 登録 ID は DPS でのデバイス登録を識別し、デバイスが登録される DPS インスタンス (ID スコープ) に対して一意である必要があります。

登録グループの場合、サブジェクト共通名 (CN) により、IoT Hub に登録されるデバイス ID が設定されます。 デバイス ID は、登録グループ内の認証済みデバイスの登録レコードに表示されます。 個別登録では、デバイス ID は登録エントリで設定できます。 登録エントリで設定されていない場合、サブジェクト共通名 (CN) が使用されます。

詳細については、X.509 CA 証明書で署名されたデバイスの認証に関するページを参照してください。

DPS デバイス チェーンの要件

デバイスから登録グループを使用した DPS 経由での登録が試行されている場合、デバイスによってリーフ証明書から検証済みの証明書までの証明書チェーンが送信される必要があります。 それ以外の場合、認証は失敗します。

たとえば、ルート証明書のみが検証され、中間証明書が登録グループにアップロードされている場合、デバイスによってリーフ証明書から検証済みのルート証明書に至るまでの証明書チェーンが提示される必要があります。 この証明書チェーンには、間にあるすべての中間証明書が含まれます。 DPS が証明書チェーンを検証済みの証明書まで追跡できない場合、認証は失敗します。

たとえば、ある会社でデバイスに次のデバイス チェーンを使用しているとします。

デバイス証明書チェーンの例を示す図。

この例では、ルート証明書は DPS で検証され、intermediate2 証明書は登録グループにアップロードされます。

ルート証明書と中間 2 証明書が DPS にアップロードされていることを示す図。

プロビジョニング中にデバイスから次のデバイス チェーンのみが送信された場合、認証は失敗します。 DPS は intermediate1 証明書の有効性を仮定して認証を試行できないためです。

証明書チェーンがルートにチェーンされないために認証に失敗したことを示す図。

プロビジョニング中にデバイスから次のような完全なデバイス チェーンが送信された場合、DPS はデバイスの認証を試みることができます。

成功したデバイス証明書チェーンを示す図。

証明書に対する DPS 操作の順序

デバイスがプロビジョニング サービスに接続すると、サービスはデバイス (リーフ) 証明書から始まる証明書チェーンを走査し、対応する登録エントリを探します。 チェーン内で検出された最初のエントリを使って、デバイスをプロビジョニングするかどうか判断します。 つまり、デバイス証明書に個別の登録がある場合、プロビジョニング サービスはそのエントリを適用します。 デバイスの個別の登録がない場合、サービスは最初の中間証明書に対応する登録グループを検索します。 それが見つかると、そのエントリが適用されます。見つからない場合は、次の中間証明書の登録グループを検索し、そのようにしてチェーンをルートまで下に移動します。

サービスは次のようにして、最初に見つかったエントリを適用します。

  • 最初に見つけた登録エントリが有効な場合、サービスはデバイスをプロビジョニングします。
  • 最初に見つかった登録エントリが無効である場合、サービスはデバイスをプロビジョニングしません。
  • デバイスの証明書チェーン内のどの証明書にも登録エントリが見つからない場合、サービスはデバイスをプロビジョニングしません。

デバイスの証明書チェーン内の各証明書を登録エントリで指定できますが、DPS インスタンス内の 1 つのエントリでのみ指定できます。

このメカニズムと証明書チェーン階層構造により、個別のデバイスやデバイス グループへのアクセスを柔軟に制御できます。 たとえば、次の証明書チェーンを持つ 5 つのデバイスがあるとします。

  • "デバイス 1": ルート証明書 -> 証明書 A -> デバイス 1 の証明書
  • "デバイス 2": ルート証明書 -> 証明書 A -> デバイス 2 の証明書
  • "デバイス 3": ルート証明書 -> 証明書 A -> デバイス 3 の証明書
  • "デバイス 4": ルート証明書 -> 証明書 B -> デバイス 4 の証明書
  • "デバイス 5": ルート証明書 -> 証明書 B -> デバイス 5 の証明書

最初に、5 つすべてのデバイスのアクセスを有効にする、ルート証明書の有効なグループ登録エントリを 1 つ作成します。 後で証明書 B が侵害された場合には、証明書 B に無効な登録グループ エントリを作成して、デバイス 4 とデバイス 5 が登録されるのを防ぐことができます。 さらにその後、デバイス 3 が侵害された場合には、デバイス 3 の証明書に無効な個別登録エントリを作成できます。 これによりデバイス 3 へのアクセスが取り消されますが、デバイス 1 とデバイス 2 ではまだ登録が可能です。