Azure IoT Edge での証明書の使用方法について理解する

適用対象: IoT Edge 1.5

IoT Edge では、さまざまな種類の証明書をさまざまな目的で使用します。 この記事では、IoT Edge が Azure IoT Hub と IoT Edge ゲートウェイのシナリオで証明書を使用する方法について説明します。

まとめ

IoT Edge では、これらのコア シナリオで証明書が使用されます。 それぞれのシナリオの詳細については、リンクを使用してください。

前提条件

• 公開キー暗号化、キー ペア、公開キーと秘密キーでデータを暗号化または暗号化解除する方法について基本的な理解が必要です。 IoT Edge で公開キー暗号化を使用する方法の詳細については、「公開キー暗号化と X.509 公開キー基盤について理解する」を参照してください。
• IoT Edge と IoT Hub の関係の基本的な理解が必要です。 詳細については、「Azure IoT Edge ランタイムとそのアーキテクチャの概要」を参照してください。

単一デバイスのシナリオ

IoT Edge 証明書の概念を学習するために、 EdgeGateway という名前の IoT Edge デバイスが ContosoIotHub という名前の Azure IoT Hub に接続するシナリオを想像してください。 この例では、すべての認証で対称キーではなく X.509 証明書認証が使用されます。 このシナリオで信頼を確立するには、IoT Hub と IoT Edge デバイスが本物であることを保証する必要があります: 「このデバイスは本物で有効であるか?」、「IoT Hub の ID は正しいか?」。 シナリオの図を次に示します。

この記事では、各質問に対する回答について説明し、後のセクションで例を展開します。

デバイスで IoT Hub の ID が確認される

EdgeGateway は実際の ContosoIotHub とどのように通信しているかを確認しますか? EdgeGateway がクラウドと通信すると、エンドポイント ContosoIoTHub.Azure-devices.NET に接続されます。 エンドポイントが本物であることを確認するために、IoT Edge では 識別 (ID) を表示するための ContosoIoTHub が必要です。 ID は、EdgeGateway が信頼する機関によって発行されたものである必要があります。 IoT Hub ID を確認するために、IoT Edge と IoT Hub は TLS ハンドシェイク プロトコルを使用して IoT Hub のサーバー ID を確認します。 次の図は、 TLS ハンドシェイクを示しています。 一部の詳細は、シンプルにするために取り残されています。 TLS ハンドシェイク プロトコルの詳細については、Wikipedia の TLS ハンドシェイクを参照してください。

このコンテキストでは、暗号アルゴリズムの正確な詳細を知る必要はありません。 重要なのは、アルゴリズムは、サーバーが公開キーとペアになっている秘密キーを所有していることを確認することです。 このチェックは、証明書の発表者が証明書をコピーまたは盗んでいないことを証明します。 顔が写真と一致する写真 ID を考えてみましょう。 誰かがあなたのIDを盗んだ場合、あなたの顔は一意であるため、それを使用することはできません。 暗号化キーの場合、キーの組は関連付けられており、一意です。 暗号アルゴリズムでは、顔を写真 ID と照合する代わりに、キー ペアを使用して ID を検証します。

このシナリオでは、ContosoIotHub は次の証明書チェーンを示しています。

ルート証明機関 (CA) は、Baltimore CyberTrust Root 証明書です。 DigiCert はこのルート証明書に署名し、広く信頼され、多くのオペレーティング システムに格納されています。 たとえば、Ubuntu と Windows の両方で、既定の証明書ストアに含まれています。

Windows 証明書ストア:

Ubuntu 証明書ストア:

デバイスが Baltimore CyberTrust Root 証明書を確認すると、既に OS に存在します。 EdgeGateway の観点からは、ContosoIotHub の証明書チェーンは OS が信頼するルート CA によって署名されているため、証明書は信頼できます。 この証明書は、 IoT Hub サーバー証明書と呼ばれます。 IoT Hub サーバー証明書の詳細については、 IoT Hub でのトランスポート層セキュリティ (TLS) のサポートに関する説明を参照してください。

まとめると、次の理由により、EdgeGateway では ContosoIotHub の ID を検証して信頼できます。

• ContosoIotHub が IoT Hub サーバー証明書を提示
• このサーバー証明書は OS 証明書ストアで信頼されている
• ContosoIotHub の公開キーで暗号化されたデータは、ContosoIotHub によって暗号化解除でき、秘密キーを保持していることが証明される

IoT Hub は IoT Edge デバイス ID を検証する

ContosoIotHub は、EdgeGateway と通信していることをどのように確認しますか? IoT Hub は相互 TLS (mTLS) をサポートするため、クライアント認証 TLS ハンドシェイク中に EdgeGateway の証明書をチェックします。 わかりやすくするために、次の図ではいくつかの手順を省略します。

この場合、EdgeGateway はその IoT Edge デバイス ID 証明書を提供します。 ContosoIotHub の観点から、指定された証明書の拇印がそのレコードと一致し、EdgeGateway に提示された証明書と組み合わせた秘密キーがあることを確認します。 IoT Hub で IoT Edge デバイスをプロビジョニングする場合は、拇印を提供します。 IoT Hub では、拇印を使用して証明書を検証します。

たとえば、次のコマンドを使用して 、EdgeGateway で ID 証明書の拇印を取得します。

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

このコマンドによって証明書 SHA256 の拇印が出力されます。

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

IoT Hub に登録されている EdgeGateway デバイスの SHA256 拇印の値を表示すると、 EdgeGateway の拇印と一致することがわかります。

要約すると、EdgeGateway は有効な IoT Edge デバイス ID 証明書と、IoT Hub に登録されたものと一致する拇印を提示するため、ContosoIotHub は EdgeGateway を信頼します。

証明書構築プロセスの詳細については、「X.509 証明書を使用して Linux で IoT Edge デバイスを作成およびプロビジョニングする」を参照してください。

モジュール ID 操作のための証明書の使用

証明書の検証図では、IoT Edge は証明書のみを使用して IoT Hub と通信するように見えます。 IoT Edge には、いくつかのモジュールがあります。 IoT Edge では、証明書を使用して、メッセージを送信するモジュールのモジュール ID を管理します。 モジュールは、IoT Hub に対する認証には証明書を使用しませんが、IoT Edge モジュール ランタイムが生成する秘密キーから派生した SAS キーを使用します。 これらの SAS キーは、デバイス ID 証明書の有効期限が切れても変わりません。 証明書の有効期限が切れると、 edgeHub は引き続き実行されますが、失敗するのはモジュール ID 操作だけです。

SAS キーはシークレットから派生し、IoT Edge は人間の介入のリスクなしにキーを管理するため、モジュールと IoT Hub の間の対話は安全です。

IoT Edge をゲートウェイとして使用する入れ子になったデバイス階層のシナリオ

これで、IoT Edge と IoT Hub の間の単純な相互作用について理解できました。 ただし、IoT Edge は、ダウンストリーム デバイスまたはその他の IoT Edge デバイスのゲートウェイとして機能することもできます。 これらの通信チャネルは暗号化され、信頼されている必要があります。 複雑さが増したため、サンプル シナリオを拡張してダウンストリーム デバイスを含めましょう。

TempSensor という名前の通常の IoT デバイスを追加します。これは、IoT Hub ContosoIotHub に接続する親 IoT Edge デバイス EdgeGateway に接続します。 以前と同様に、すべての認証で X.509 証明書認証が使用されます。 このシナリオでは、「TempSensor デバイスは正当か」と「EdgeGateway の ID は正しいか」という 2 つの質問が発生します。 シナリオを次に示します。

デバイスでゲートウェイ ID が確認される

TempSensor では、正規の EdgeGateway と通信中であることがどのように検証されますか? TempSensor が EdgeGateway と通信する必要がある場合、TempSensor には ID を表示するために EdgeGateway が必要です。 ID は、TempSensor が信頼する機関によって発行されたものである必要があります。

このフローは、EdgeGateway が ContosoIotHub と通信する場合と同じです。 TempSensor と EdgeGateway は、TLS ハンドシェイク プロトコルを使用して EdgeGateway の ID を確認します。 2 つの重要な詳細があります。

• ホスト名の特殊性: EdgeGateway によって提示される証明書は、TempSensor が EdgeGateway への接続に使用するものと同じホスト名 (ドメインまたは IP アドレス) に対して発行される必要があります。
• 自己署名ルート CA の特殊性: EdgeGateway によって提示される証明書チェーンは、OS の既定の信頼されたルート ストアにない可能性があります。

詳細を理解するために、まず EdgeGateway によって提示される証明書チェーンを調べてみましょう。

ホスト名の特殊性

証明書の共通名 CN = edgegateway.local がチェーンの一番上にリストされます。 edgegateway.local は、edgeHub のサーバー証明書の共通名です。 edgegateway.local は、TempSensor と EdgeGateway が接続されているローカル ネットワーク (LAN または VNet) 上の EdgeGateway のホスト名でもあります。 192.168.1.23 などのプライベート IP アドレスまたは図のような完全修飾ドメイン名 (FQDN) の可能性があります。 edgeHub サーバー証明書は、IoT Edge config.toml ファイルで定義されている hostname パラメーターを使用して生成されます。 edgeHub サーバー証明書と Edge CA 証明書を混同しないでください。 Edge CA 証明書の管理の詳細については、IoT Edge 証明書の管理の説明を参照してください。

TempSensor が EdgeGateway に接続すると、TempSensor はホスト名 edgegateway.local を使用して EdgeGateway に接続します。 TempSensor は、EdgeGateway によって提示された証明書をチェックし、証明書の共通名が edgegateway.local であることを確認します。 証明書の共通名が異なる場合、TempSensor は接続を拒否します。

EdgeGateway に自身のホスト名を通知する必要があるのはなぜですか?

EdgeGateway には、ネットワーク上の他のクライアントがどのように接続できるかを知るための信頼性の高い方法はありません。 たとえば、プライベート ネットワークでは、EdgeGateway を 10.0.0.2 または example-mdns-hostname.local としてリストする DHCP サーバーまたは mDNS サービスが存在する可能性があります。 ただし、ネットワークによっては、edgegateway.local を EdgeGateway の IP アドレス 10.0.0.2 にマッピングする DNS サーバーが存在する場合があります。

この問題を解決するために、IoT Edge では config.toml で構成されたホスト名の値を使用し、そのサーバー証明書を作成します。 要求が edgeHub モジュールに送信されると、適切な証明書共通名 (CN) を持つ証明書が提示されます。

IoT Edge で証明書が作成されるのはなぜですか?

この例では、証明書チェーンに iotedged workload ca edgegateway があることに注意してください。 Edge CA (以前、バージョン 1.1 では Device CA と呼ばれていました) として知られる IoT Edge デバイス上に存在する認証機関 (CA) です。 前の例の Baltimore CyberTrust Root CA と同様に、Edge CA では他の証明書を発行できます。 最も重要なのは、この例でも、サーバー証明書は edgeHub モジュールに発行されることです。 ただし、IoT Edge デバイスで実行されている他のモジュールに証明書を発行することもできます。

デバイスで発行者証明書を保持するのは危険ではありませんか?

Edge CA は、制限のある、信頼性の低い、コストが高い、または接続性のないソリューションを有効にするように設計されていますが、同時に、証明書の更新に関する厳格な規制やポリシーがあります。 Edge CA がなければ、IoT Edge (特に edgeHub) は機能しません。

本番環境で Edge CA を保護するには:

• EdgeCA の秘密キーをトラステッド プラットフォーム モジュール (TPM) に配置します。できれば、秘密キーが一時的に生成され、TPM から離れない方法で行ってください。
• Edge CA がロールアップする公開キー基盤 (PKI) を使用します。 これにより、侵害された証明書の更新を無効または拒否できるようになります。 PKI は、顧客の IT 部門が方法を把握している場合は顧客の IT 部門によって (低コスト)、または商用の PKI プロバイダーによって管理できます。

自己署名ルート CA の特殊性

edgeHub モジュールは、すべての受信トラフィックを処理して IoT Edge を構成する重要なコンポーネントです。 この例では、Edge CA によって発行された証明書を使用します。これは、自己署名ルート CA によって発行されます。 このルート CA は OS によって信頼されていないため、TempSensor が信頼する唯一の方法は、CA 証明書をデバイスにインストールすることです。 これは、信頼バンドル シナリオとも呼ばれ、チェーンを信頼する必要があるクライアントにルートを配布する必要があります。 信頼バンドル シナリオは、デバイスにアクセスして証明書をインストールする必要があるため、面倒な場合があります。 証明書のインストールには計画が必要です。 スクリプトを使用して行うか、製造時に追加するか、OS イメージにプリインストールすることができます。

これらの概念をすべて適用すると、TempSensor は本物の EdgeGateway と通信中であることを確認できます。これは、アドレスに一致する証明書を提示し、その証明書が信頼できるルートによって署名されているためです。

証明書チェーンを確認するには、openssl デバイスで を使用します。 この例では、接続用のホスト名が depth 0 証明書の CN と一致し、ルート CA が一致していることに注目してください。

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

openssl コマンドの詳細については、OpenSSL のドキュメントをご覧ください。

既定で /var/lib/aziot/certd/certs に格納されている証明書を調べることもできます。 ディレクトリ内に、Edge CA 証明書、デバイス ID 証明書、モジュール証明書があるのを確認できます。 openssl x509 コマンドを使用して、証明書を検査できます。 次に例を示します。

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

まとめると、TempSensor が EdgeGateway を信頼できる理由は次のとおりです。

• edgeHub モジュールが、edgegateway.local の有効な IoT Edge モジュール サーバー証明書を提示した
• その証明書は、 によって発行された my_private_root_CA によって発行されている
• このプライベート ルート CA は、以前に信頼されたルート CA として TempSensor にも格納されている
• 暗号アルゴリズムは、所有権と発行チェーンが信頼できることを確認する

他のモジュールの証明書

他のモジュールは、Edge CA によって発行されたサーバー証明書を取得できます。 たとえば、Web インターフェースを持つ Grafana モジュールです。 Edge CA から証明書を取得することもできます。 モジュールは、コンテナーでホストされるダウンストリーム デバイスとして扱われます。 ただし、IoT Edge モジュール ランタイムから証明書を取得できることは特別な特権です。 モジュールは、ワークロード API を呼び出して、構成済みの Edge CA にチェーンされたサーバー証明書を受け取ります。

ゲートウェイによってデバイス ID が検証される

EdgeGateway が TempSensor と通信していることを確認する方法 EdgeGateway では 、TLS クライアント認証 を使用して TempSensor を認証します。

このシーケンスは、 ContosoIotHub がデバイスをチェックするのと似ています。 ただし、ゲートウェイ シナリオでは、 EdgeGateway は証明書レコードの信頼できるソースとして ContosoIotHub に依存しています。 また、クラウド への接続がない場合、EdgeGateway はオフラインのコピーまたはキャッシュも保持します。

まとめると、EdgeGateway が TempSensor を信頼できる理由は次のとおりです。

• TempSensor は、その名前に対して有効な IoT デバイス ID 証明書 を提示します
• ID 証明書の拇印は、ContosoIotHub にアップロードされたものと一致する
• 暗号アルゴリズムは、所有権と発行チェーンが信頼できることを確認する

証明書と管理の取得先

ほとんどの場合、独自の証明書を指定するか、自動生成された証明書を使用します。 たとえば、Edge CA と edgeHub 証明書は自動生成されます。

ただし、ベスト プラクティスは、セキュリティで保護されたトランスポート (EST) サーバー経由の登録を使用して x509 証明書を管理するようにデバイスを設定することです。 EST サーバーを使用すると、手動で証明書を処理してデバイスにインストールすることを回避できます。 EST サーバーの使用の詳細については、「Azure IoT Edge 用に Enrollment over Secure Transport サーバーを構成する」をご覧ください。

証明書を使用して EST サーバーに対して認証することもできます。 これらの証明書は、他の証明書を発行するために EST サーバーで認証されます。 証明書サービスは、ブートストラップ証明書を使用して EST サーバーで認証します。 ブートストラップ証明書は有効期間が長いです。 証明書サービスは、最初に認証を行うときに、EST サーバーに ID 証明書を要求します。 ID 証明書は、同じサーバーに対する将来の EST 要求で使用されます。

EST サーバーを使用できない場合は、PKI プロバイダーに証明書を要求します。 IoT Hub と IoT Edge デバイスで証明書ファイルを手動で管理します。 詳細については、「 IoT Edge デバイスで証明書を管理する」を参照してください。

概念実証開発の場合は、テスト証明書を作成します。 詳細については、「IoT Edge デバイスの機能をテストするためのデモ用の証明書を作成する」をご覧ください。

IoT の証明書

証明機関

証明機関 (CA) がデジタル証明書を発行します。 CA は、証明書の所有者と受信者の間で信頼されたサード パーティとして機能します。 デジタル証明書は、受信者が公開キーを所有していると証明します。 信頼の証明書チェーンは、証明機関が発行するすべての証明書の信頼の基礎となるルート証明書で始まります。 ルート証明書の所有者は、追加の中間証明書 (ダウンストリーム デバイス証明書) を発行できます。

ルート CA 証明書

ルート CA 証明書は、プロセスの信頼のルートです。 運用環境では、通常、Baltimore、Verisign、DigiCert などの信頼できる商用証明機関からこの CA 証明書を購入します。 IoT Edge デバイスに接続するすべてのデバイスを制御する場合は、企業の証明機関を使用できます。 どちらの場合も、IoT Edge から IoT Hub への証明書チェーンではルート CA 証明書が使用されます。 ダウンストリーム IoT デバイスは、ルート証明書を信頼する必要があります。 ルート CA 証明書を信頼されたルート証明機関ストアに格納するか、アプリケーション コードで証明書の詳細を指定します。

中間証明書

セキュリティで保護されたデバイスの一般的な製造プロセスでは、漏えいや漏洩のリスクがあるため、製造元がルート CA 証明書を直接使用することはほとんどありません。 ルート CA 証明書は、中間 CA 証明書を 1 つ以上作成し、デジタル署名を行います。 中間証明書は 1 つでもチェーンでもかまいません。 中間証明書のチェーンを必要とするシナリオは次のとおりです。

• 製造業者の社内部門の階層
• デバイスの生産時にシリアルに関連付けられた複数の企業
• 顧客がルート CA を購入し、製造元が顧客に代わってデバイスに署名するための署名証明書を派生させる

製造元は、このチェーンの最後にある中間 CA 証明書を使用して、エンド デバイスに配置された Edge CA 証明書に署名します。 製造工場は、これらの中間証明書を厳密に保護します。 厳格な物理プロセスと電子プロセスが、その使用を制御します。

次のステップ

• IoT Edge デバイスに証明書をインストールし、config ファイルからそれらを参照する方法の詳細については、「IoT Edge デバイスで証明書を管理する」を参照してください。
• Azure IoT Edge モジュールについて
• 透過的なゲートウェイとして機能するように IoT Edge デバイスを構成します。
• この記事では、証明書を使用して、IoT Edge デバイス上の異なるコンポーネント間、または IoT Edge デバイスとダウンストリーム デバイス間の接続をセキュリティで保護する方法について説明します。 また、証明書を使用して、IoT Hub に対して IoT Edge デバイスを認証することもできます。 これらの認証証明書は異なりますが、この記事では説明されません。 証明書を使用してデバイスを認証する方法の詳細については、「X.509 証明書を使用して IoT Edge デバイスを作成およびプロビジョニングする」を参照してください。