X.509 証明書の構成証明

  • [アーティクル]

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

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 証明書です。 証明書チェーンの終端、つまりトラスト アンカーになります。 ルート証明書は組織が自ら発行することも、ルート証明機関から購入することもできます。 詳細については、「X.509 CA 証明書を入手する」をご覧ください。 ルート証明書は、ルート CA 証明書とも呼ばれます。

中間証明機関の証明書

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

中間証明書が役に立つ理由

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

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

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

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

個別登録または登録グループ エントリで使用されるリーフ証明書では、サブジェクト共通名 (CN) が登録 ID に設定されている必要があります。 登録 ID は DPS でのデバイス登録を識別し、デバイスが登録される DPS インスタンス (ID スコープ) に対して一意である必要があります。 登録 ID は、英数字と特殊文字 ('-'、'.'、'_'、':') から成る、大文字と小文字が区別されない文字列です。 最後の文字は、英数字またはダッシュ ('-') である必要があります。 DPS では、最大 128 文字の登録 ID がサポートされます。ただし、X.509 証明書のサブジェクト共通名の最大長は 64 文字です。 したがって、X.509 証明書を使用する場合、登録 ID は 64 文字に制限されます。

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

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

X.509 証明書を使用してプロビジョニング サービスへのデバイスのアクセスを制御する

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

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

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

相互 TLS のサポート

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

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

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

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

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

Example device certificate chain

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

Example root verified

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

Example failing certificate chain

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

Example device certificate chain

証明書に対する 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 ではまだ登録が可能です。