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 Edge デバイスと IoT Hub の接続を示す信頼シナリオの状態図

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

デバイスが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 に次の証明書チェーンが表示されます。

{c1}{c0}{sb0}IoT Hub の中間証明書チェーンとルート証明書チェーンを示すフロー図{/sb0}{/c0}{/c1}

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

デバイスが DigiCert グローバル ルート G2 証明書を確認すると、既に OS に存在します。 EdgeGateway の観点からは、ContosoIotHub の証明書チェーンは OS が信頼するルート CA によって署名されているため、証明書は信頼できます。 この証明書は、IoT Hub サーバー証明書と呼ばれます。 IoT Hub サーバー証明書の詳細については、「IoT Hub での Transport Layer Security (TLS) のサポート」を参照してください。

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

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

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

ContosoIotHub は、EdgeGateway と通信していることをどのように確認しますか? IoT Hub は mutual TLS (mTLS) をサポートしているため、client で認証された 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 EdgeGateway に接続する親IoT Edgeデバイス ContosoIotHub に接続されます。 以前と同様に、すべての認証で X.509 証明書認証が使用されます。 このシナリオでは、「TempSensor デバイスは正当か」と「EdgeGateway の ID は正しいか」という 2 つの質問が発生します。シナリオを次の図に示します。

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

TempSensorは、本物のEdgeGatewayと通信していることをどうやって確認しますか？ TempSensorがEdgeGatewayと通信する場合、TempSensorはEdgeGatewayが必要です ID を表示するために。 ID は、信頼できる TempSensor 機関から取得する必要があります。

フローは、 EdgeGateway が ContosoIotHubと話すときと同じです。 TempSensor と EdgeGateway は TLS ハンドシェイク プロトコルを使用して、EdgeGateway のアイデンティティを確認します。 2 つの重要な詳細が目立ちます。

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

詳細を理解するには、まず、 EdgeGateway が提示する証明書チェーンを調べます。

ホスト名の特殊性

証明書の共通名 CN = edgegateway.local チェーンの一番上に表示されます。 edgegateway.local は、 edgeHub サーバー証明書の共通名です。 edgegateway.localは、EdgeGatewayとTempSensor接続するローカル ネットワーク (LAN または VNet) 上のEdgeGatewayのホスト名でもあります。 192.168.1.23などのプライベート IP アドレス、または図のような完全修飾ドメイン名 (FQDN) を指定できます。 edgeHub サーバー証明書を生成するには、hostnameで定義されている パラメーターを使用します。 edgeHub サーバー証明書とエッジ CA 証明書を混同しないでください。 Edge CA 証明書の管理の詳細については、「Manage 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 IP アドレスEdgeGatewayに10.0.0.2をマップする DNS サーバーが存在する場合があります。

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

IoT Edge はなぜ証明書を作成するのか？

この例では、証明書チェーンに iotedged workload ca edgegateway があることに注意してください。 これは、IoT Edge デバイスに存在する証明機関 (CA) です。Edge CA (旧称: Device CA バージョン 1.1)。 前の例の DigiCert グローバル ルート G2 と同様に、 Edge CA は他の証明書を発行できます。 最も重要なのは、この例でも、 edgeHub モジュールにサーバー証明書を発行することです。 ただし、IoT Edge デバイスで実行されている他のモジュールに証明書を発行することもできます。

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

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

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

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

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

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

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

証明書チェーンを確認するには、openssl デバイスでTempSensorを使用できます。 この例では、接続のホスト名が 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が表示されます。
• 証明書は、によって発行された my_private_root_CA によって発行されます。
• このプライベート ルート CA は、先ほど信頼されたルート CA として TempSensor にも格納されます。
• 暗号化アルゴリズムは、所有権と発行チェーンが信頼できることを確認します。

他のモジュールの証明書

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

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

EdgeGateway TempSensorと通信していることを確認するにはどうすればよいですか? EdgeGateway では、 TLS client authentication を使用して TempSensorを認証します。

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

要約すると、 EdgeGateway は次の理由で TempSensor を信頼できます。

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

証明書と管理の取得先

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

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

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

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

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

IoT の証明書

証明機関

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

ルート CA 証明書

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

中間証明書

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

• 製造元内の部門の階層。
• 複数の企業が、デバイスの製造に順次関与します。
• 顧客がルート CA を購入し、製造元が顧客の代わりにデバイスに署名するための署名証明書を派生させます。

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

次のステップ

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