IoT 業界における X.509 CA 証明書の概念理解Conceptual understanding of X.509 CA certificates in the IoT industry

この記事では、IoT デバイスの製造および IoT Hub に対する認証で X.509 証明機関 (CA) 証明書を使用する価値について説明します。This article describes the value of using X.509 certificate authority (CA) certificates in IoT device manufacturing and authentication to IoT Hub. サプライ チェーンの設定に関する情報と主な利点についても記載します。It includes information about supply chain setup and highlight advantages.

この記事では、次の内容について説明します。This article describes:

  • X.509 CA 証明書の概要と入手方法What X.509 CA certificates are and how to get them

  • X.509 CA 証明書を IoT Hub に登録する方法How to register your X.509 CA certificate to IoT Hub

  • X.509 CA ベースの認証用に製造サプライ チェーンを設定する方法How to set up a manufacturing supply chain for X.509 CA-based authentication

  • X.509 CA で署名されたデバイスから IoT Hub に接続する方法How devices signed with X.509 CA connect to IoT Hub

概要Overview

X.509 証明機関 (CA) 認証は、サプライ チェーンにおけるデバイス ID の作成とライフサイクル管理を劇的に簡素化する方法を使用して IoT Hub に対してデバイスを認証するための手法です。X.509 Certificate Authority (CA) authentication is an approach for authenticating devices to IoT Hub using a method that dramatically simplifies device identity creation and life-cycle management in the supply chain.

X.509 CA 認証の特徴的な属性として、CA 証明書がそのダウンストリームのデバイスとの間に持つ一対多のリレーションシップがあります。A distinguishing attribute of the X.509 CA authentication is a one-to-many relationship a CA certificate has with its downstream devices. このリレーションシップにより、X.509 CA 証明書を 1 回登録するだけで多数のデバイスを IoT Hub に登録することが可能になります。このリレーションシップがなければ、デバイスごとにデバイスの一意の証明書をあらかじめ登録してから、デバイスを接続する必要があります。This relationship enables registration of any number of devices into IoT Hub by registering an X.509 CA certificate once, otherwise device unique certificates must be pre-registered for every device before a device can connect. また、この一対多のリレーションシップにより、デバイス証明書のライフサイクル管理操作も簡単になります。This one-to-many relationship also simplifies device certificates life-cycle management operations.

X.509 CA 認証のもう 1 つの重要な属性として、サプライ チェーンのロジスティクスの簡略化があります。Another important attribute of the X.509 CA authentication is simplification of supply chain logistics. デバイスのセキュリティで保護された認証では、各デバイスが信頼の基盤として一意のシークレット (キーなど) を保持していることが必要となります。Secure authentication of devices requires that each device holds a unique secret like a key as basis for trust. 証明書ベースの認証では、このシークレットは秘密キーです。In certificates-based authentication, this secret is a private key. 一般的なデバイス製造フローには、複数のステップと管理者が含まれています。A typical device manufacturing flow involves multiple steps and custodians. 複数の管理者間でデバイスの秘密キーを安全に管理し、信頼を維持することは難しいうえにコストも高くなります。Securely managing device private keys across multiple custodians and maintaining trust is difficult and expensive. 証明機関を使用すると、各管理者にデバイスの秘密キーを委ねるのではなく、各管理者に署名して暗号の信頼チェーンを確立するため、この問題は解決します。Using certificate authorities solves this problem by signing each custodian into a cryptographic chain of trust rather than entrusting them with device private keys. 次に、各管理者は、製造フローのそれぞれのプロセス ステップでデバイスに署名します。Each custodian in turn signs devices at their respective process step of the manufacturing flow. 総合的な結果として、暗号の信頼チェーンの使用によりアカウンタビリティが組み込まれた最適なサプライ チェーンになります。The overall result is an optimal supply chain with built-in accountability through use of the cryptographic chain of trust. 注目すべきは、このプロセスでは、デバイスで一意の秘密キーが保護されている場合にセキュリティが最も強力になることです。It is worth noting that this process yields the most security when devices protect their unique private keys. この目的に向けて、公開されることのない秘密キーを内部的に生成できるハードウェア セキュア モジュール (HSM) の使用を強くお勧めします。To this end, we urge the use of Hardware Secure Modules (HSM) capable of internally generating private keys that will never see the light of day.

この記事では、理解を深めるために実際の例を使用しながら、サプライ チェーンの設定からデバイス接続まで X.509 CA 認証の使用を詳しく説明します。This article offers an end-to-end view of using the X.509 CA authentication, from supply chain setup to device connection, while making use of a real world example to solidify understanding.

はじめにIntroduction

X.509 CA 証明書はデジタル証明書であり、その所有者は他の証明書に署名することができます。The X.509 CA certificate is a digital certificate whose holder can sign other certificates. このデジタル証明書は、IETF の RFC 5280 標準で規定されている証明書形式の標準に準拠していることから X.509 であり、その所有者が他の証明書に署名できることから証明機関 (CA) でもあります。This digital certificate is X.509 because it conforms to a certificate formatting standard prescribed by IETF's RFC 5280 standard, and is a certificate authority (CA) because its holder can sign other certificates.

X.509 CA の使用について、具体的な例との関連で理解を深めていきます。The use of X.509 CA is best understood in relation to a concrete example. Company-X は、専門施設向けに設計された Smart-X-Widget のメーカーです。Consider Company-X, a maker of Smart-X-Widgets designed for professional installation. Company-X は、製造とインストールの両方を外部に委託しています。Company-X outsources both manufacturing and installation. これは、製造会社 Factory-Y に Smart-X-Widget の製造を委託し、サービス プロバイダー Technician-Z にインストールを委託しています。It contracts manufacturer Factory-Y to manufacture the Smart-X-Widgets, and service provider Technician-Z to install. Company-X は、Smart-X-Widget をインストールの目的で Factory-Y から Technician-Z に直接出荷し、インストール後に Company-X が介入することなく Company-X の IoT Hub のインスタンスに直接接続することを希望しています。Company-X desires that Smart-X-Widget directly ships from Factory-Y to Technician-Z for installation and that it connects directly to Company-X's instance of IoT Hub after installation without further intervention from Company-X. これを実現するには、Company-X は、Smart-X-Widget を自動接続するための準備として 1 回限りの設定操作を数回実行する必要があります。To make this happen, Company-X need to complete a few one-time setup operations to prime Smart-X-Widget for automatic connection. このエンド ツー エンドのシナリオを考慮したうえで、この記事の残りの部分は次のように構成されています。With the end-to-end scenario in mind, the rest of this article is structured as follows:

  • X.509 CA 証明書を取得するAcquire the X.509 CA certificate

  • X.509 CA 証明書を IoT Hub に登録するRegister X.509 CA certificate to IoT Hub

  • デバイスに署名して証明書の信頼チェーンに入れるSign devices into a certificate chain of trust

  • デバイスの接続Device connection

X.509 CA 証明書を取得するAcquire the X.509 CA certificate

Company-X には、公的なルート証明機関から X.509 CA 証明書を購入するか、または自己署名プロセスを通じて X.509 CA 証明書を作成するかの選択肢があります。Company-X has the option of purchasing an X.509 CA certificate from a public root certificate authority or creating one through a self-signed process. アプリケーションのシナリオに応じて、どちらかの選択肢の方が適切かが異なります。One option would be optimal over the other depending on the application scenario. この選択肢に関係なく、このプロセスには、公開キーと秘密キーのペアの生成と公開キーによる証明書への署名という 2 つの基本的な手順が伴います。Regardless of the option, the process entails two fundamental steps, generating a public/private key pair and signing the public key into a certificate.

X509CA 証明書を生成するフロー

これらの手順を実行する方法の詳細は、それぞれのサービス プロバイダーによって異なります。Details on how to accomplish these steps differ with various service providers.

X.509 CA 証明書の購入Purchasing an X.509 CA certificate

CA 証明書を購入することで、既知のルート CA が IoT デバイスの接続時にデバイスの正当性を保証する信頼されたサード パーティとして機能するという利点が得られます。Purchasing a CA certificate has the benefit of having a well-known root CA act as a trusted third party to vouch for the legitimacy of IoT devices when the devices connect. Company-X は、Smart-X-Widget が IoT Hub に最初に接続した後にサード パーティ製の製品やサービスと対話することを考えている場合は、このオプションを選択します。Company-X would choose this option if they intend Smart-X-Widget to interact with third party products or services after initial connection to IoT Hub.

X.509 CA 証明書を購入するには、Company-X は、ルート証明書のサービス プロバイダーを選択する必要があります。To purchase an X.509 CA certificate, Company-X would choose a root certificates services provider. "ルート CA" という語句をインターネットで検索すると、良い手がかりが得られます。An internet search for the phrase 'Root CA' will yield good leads. ルート CA により、Company-X に対して、公開キーと秘密キーのペアの作成方法と、サービスの証明書署名要求 (CSR) の生成方法が示されます。The root CA will guide Company-X on how to create the public/private key pair and how to generate a Certificate Signing Request (CSR) for their services. CSR は、証明機関からの証明書を申請する正式なプロセスです。A CSR is the formal process of applying for a certificate from a certificate authority. この購入の結果、証明機関の証明書として使用するための証明書を取得できます。The outcome of this purchase is a certificate for use as an authority certificate. X.509 証明書の遍在性を考慮すると、この証明書は IETF の RFC 5280 標準に合わせて適切に書式設定されている可能性があります。Given the ubiquity of X.509 certificates, the certificate is likely to have been properly formatted to IETF's RFC 5280 standard.

自己署名 X.509 CA 証明書の作成Creating a Self-Signed X.509 CA certificate

ルート証明機関のようなサード パーティの署名者が関与する点を除けば、購入プロセスと自己署名 X.509 CA 証明書の作成プロセスは似ています。The process to create a Self-Signed X.509 CA certificate is similar to purchasing with the exception of involving a third party signer like the root certificate authority. この例では、Company-X が、ルート証明機関に代わってその証明機関の証明書に署名します。In our example, Company-X will sign its authority certificate instead of a root certificate authority. Company-X は、証明機関の証明書を購入する準備が整うまで、テスト目的でこのオプションを選択できます。Company-X may choose this option for testing until they're ready to purchase an authority certificate. また、Company-X は、Smart-X-Widget が IoT Hub 以外のサード パーティのサービスに接続することを目的としていない場合に運用環境で自己署名 X.509 CA 証明書を使用することもあります。Company-X may also use a self-signed X.509 CA certificate in production, if Smart-X-Widget is not intended to connect to any third party services outside of the IoT Hub.

X.509 証明書を IoT Hub に登録するRegister the X.509 certificate to IoT Hub

Company-X は、X.509 CA を IoT Hub に登録する必要があります。IoT Hub は、Smart-X-Widget を接続時に認証する役割を果たします。Company-X needs to register the X.509 CA to IoT Hub where it will serve to authenticate Smart-X-Widgets as they connect. これは 1 回限りのプロセスであり、任意の数の Smart-X-Widget デバイスの認証および管理が可能になります。This is a one-time process that enables the ability to authenticate and manage any number of Smart-X-Widget devices. このプロセスは、証明機関の証明書とデバイスとの間の一対多のリレーションシップのため 1 回限りであり、X.509 CA 認証方法を使用する主な利点の 1 つになります。This process is one-time because of a one-to-many relationship between authority certificate and devices and also constitutes one of the main advantages of using the X.509 CA authentication method. また、Smart-X-Widget デバイスごとに個別の証明書拇印をアップロードする方法もありますが、その場合は運用コストが増加します。The alternative is to upload individual certificate thumbprints for each and every Smart-X-Widget device thereby adding to operational costs.

X.509 CA 証明書の登録は、証明書のアップロードと証明書の所有証明による 2 段階のプロセスです。Registering the X.509 CA certificate is a two-step process, the certificate upload and certificate proof-of-possession.

X509CA 証明書の登録

X.509 CA 証明書のアップロードX.509 CA Certificate Upload

X.509 CA 証明書のアップロード プロセスは、IoT Hub に CA 証明書をアップロードするだけです。The X.509 CA certificate upload process is just that, upload the CA certificate to IoT Hub. IoT Hub は、ファイル形式の証明書を必要とします。IoT Hub expects the certificate in a file. Company-X は、証明書ファイルをアップロードするだけです。Company-X simply uploads the certificate file. いかなる場合においても、証明書ファイルに秘密キーを含めないでください。The certificate file MUST NOT under any circumstances contain any private keys. 公開キー基盤 (PKI) を規定する標準によるベスト プラクティスでは、この場合の Company-X の秘密の知識は Company-X 内のみに限定して存在することが求められています。Best practices from standards governing Public Key Infrastructure (PKI) mandates that knowledge of Company-X's private in this case resides exclusively within Company-X.

証明書の所有証明Proof-of-Possession of the Certificate

X.509 CA 証明書は、他のデジタル証明書と同様に、傍受されやすい公開情報です。The X.509 CA certificate, just like any digital certificate, is public information that is susceptible to eavesdropping. そのため、傍受者は、証明書を傍受し、その証明書を自分のものとしてアップロードしようとする可能性があります。As such, an eavesdropper may intercept a certificate and try to upload it as their own. この例では、IoT Hub は、Company-X がアップロードしている CA 証明書が本当に Company-X に属しているかどうかを確認します。In our example, IoT Hub would like to make sure that the CA certificate Company-X is uploading really belongs to Company-X. このためには、Company-X にチャレンジを送信して、Company-X が証明書を実際に所有していることを所有証明 (PoP) フローを通じて証明します。It does so by challenging Company-X to proof that they in fact possess the certificate through a proof-of-possession (PoP) flow. 所有証明フローは、Company-X が秘密キーを使用して署名する乱数を IoT Hub が生成することを伴います。The proof-of-possession flow entails IoT Hub generating a random number to be signed by Company-X using its private key. Company-X が PKI のベスト プラクティスに従い、秘密キーを保護した場合、所有証明チャレンジに正しく応答できる立場にあるのは Company-X のみです。If Company-X followed PKI best practices and protected their private key then only they would be in position to correctly respond to the proof-of-possession challenge. IoT Hub は、所有証明チャレンジの応答に成功すると、X.509 CA 証明書の登録に進みます。IoT Hub proceeds to register the X.509 CA certificate upon a successful response of the proof-of-possession challenge.

IoT Hub からの所有証明チャレンジに対する応答に成功すると、X.509 CA の登録が完了します。A successful response to the proof-of-possession challenge from IoT Hub completes the X.509 CA registration.

デバイスに署名して証明書の信頼チェーンに入れるSign Devices into a Certificate Chain of Trust

IoT では、各デバイスが一意の ID を保有する必要があります。IoT requires every device to possess a unique identity. これらの ID は、証明書ベースの認証スキーム用の証明書の形式になっています。These identities are in the form certificates for certificate-based authentication schemes. つまり、この例では、各 Smart-X-Widget が一意のデバイス証明書を保有している必要があります。In our example, this means every Smart-X-Widget must possess a unique device certificate. Company-X はサプライ チェーンにおいてこれについてどのように設定するでしょうか。How does Company-X setup for this in its supply chain?

これに着手するための 1 つの方法として、Smart-X-Widget 用の証明書を事前に生成し、対応する一意のデバイス秘密キーの情報をサプライ チェーン パートナーに委任します。One way to go about this is to pre-generate certificates for Smart-X-Widgets and entrusting knowledge of corresponding unique device private keys with supply chain partners. Company-X の場合、これは Factory-Y と Technician-Z に委任することを意味します。For Company-X, this means entrusting Factory-Y and Technician-Z. これは有効な方法ですが、次のように、信頼を確保するために克服しなければならない課題も伴います。While this is a valid method, it comes with challenges that must be overcome to ensure trust as follows:

  1. 秘密キーを共有しないという PKI のベスト プラクティスを無視するうえに、デバイスの秘密キーをサプライ チェーン パートナーと共有しなければならないことにより、サプライ チェーンにおける信頼構築はコストが高くなります。Having to share device private keys with supply chain partners, besides ignoring PKI best practices of never sharing private keys, makes building trust in the supply chain expensive. これは、デバイスの秘密キーを保管するための安全な部屋などの資本システムを意味します。さらに、定期的なセキュリティ監査などのプロセスの導入が必要になります。It means capital systems like secure rooms to house device private keys, and processes like periodic security audits need to be installed. どちらも、サプライ チェーンのコストを引き上げます。Both add cost to the supply chain.

  2. サプライ チェーン内のデバイスを安全にアカウンティングした後、それらをデプロイで管理することは、デバイスに一意の証明書 (したがって秘密キー) の生成時点からデバイスの廃棄時点まで、キーとデバイスのペアごとに一対一のタスクになります。Securely accounting for devices in the supply chain and later managing them in deployment becomes a one-to-one task for every key-to-device pair from the point of device unique certificate (hence private key) generation to device retirement. これにより、グループの概念が何らかの形で明示的にプロセスに組み込まれていない限り、デバイスのグループ管理は除外されます。This precludes group management of devices unless the concept of groups is explicitly built into the process somehow. したがって、安全なアカウンティングとデバイスのライフ サイクル管理は運用上の大きな負担になります。Secure accounting and device life-cycle management, therefore, becomes a heavy operations burden. この例では、Company-X がこの負担を負うことになります。In our example, Company-X would bear this burden.

X.509 CA 証明書認証は、証明書チェーンを使用することで、前述の課題に対する洗練されたソリューションを提供します。X.509 CA certificate authentication offers elegant solutions to afore listed challenges through the use of certificate chains. 証明書チェーンは、中間 CA に署名する CA から始まり、その中間 CA が別の中間 CA に署名し、最終の中間 CA がデバイスに署名するまで続きます。A certificate chain results from a CA signing an intermediate CA that in turn signs another intermediate CA and so goes on until a final intermediate CA signs a device. この例では、Company-X が Factory-Y に署名します。次に Factory-Y が Technician-Z に署名し、最後に Technician-Z が Smart-X-Widget に署名します。In our example, Company-X signs Factory-Y, which in turn signs Technician-Z that finally signs Smart-X-Widget.

証明書チェーンの階層

上記のチェーン内の証明書の伝播は、権限の論理的な引き継ぎを示します。Above cascade of certificates in the chain presents the logical hand-off of authority. 多くのサプライ チェーンは、この論理的な引き継ぎに従っています。つまり、各中間 CA は、すべての上流 CA 証明書を受信し、署名されてチェーンに入れられます。最終的に、最後の中間 CA が各デバイスに署名し、チェーンからのすべての証明機関の証明書をデバイスに挿入します。Many supply chains follow this logical hand-off whereby each intermediate CA gets signed into the chain while receiving all upstream CA certificates, and the last intermediate CA finally signs each device and inject all the authority certificates from the chain into the device. これは、工場の階層がある契約製造会社が特定の工場に製造を委託する場合に一般的です。This is common when the contract manufacturing company with a hierarchy of factories commissions a particular factory to do the manufacturing. 階層は複数レベル (たとえば、地理、製品の種類、製造ライン) で構成される場合がありますが、最後の工場だけがデバイスと対話できます。ただし、チェーンは階層の最上位から保持されます。While the hierarchy may be several levels deep (for example, by geography/product type/manufacturing line), only the factory at the end gets to interact with the device but the chain is maintained from the top of the hierarchy.

代替チェーンには、デバイスと対話する別の中間 CA が含まれる場合があります。その場合、デバイスと対話する CA が、その時点での証明書チェーンの内容を挿入します。Alternate chains may have different intermediate CA interact with the device in which case the CA interacting with the device injects certificate chain content at that point. CA の一部だけがデバイスと物理的に対話するハイブリッド モデルも可能です。Hybrid models are also possible where only some of the CA has physical interaction with the device.

この例では、Factory-Y と Technician-Z の両方が Smart-X-Widget と対話します。In our example, both Factory-Y and Technician-Z interact with the Smart-X-Widget. Company-X は Smart-X-Widget を所有していますが、実際にはサプライ チェーン全体において物理的に Smart-X-Widget と対話しません。While Company-X owns Smart-X-Widget, it actually does not physically interact with it in the entire supply chain. そのため、Smart-X-Widget の証明書の信頼チェーンは、Company-X が Factory-Y に署名し、その後 Factory-Y が Technician-Z に署名して、最後に Technician-Z が Smart-X-Widget に署名するという構成になっています。The certificate chain of trust for Smart-X-Widget therefore comprise Company-X signing Factory-Y which in turn signs Technician-Z that will then provide final signature to Smart-X-Widget. Smart-X-Widget の製造およびインストールは、それぞれの中間 CA 証明書を使用して各 Smart-X-Widget に署名する Factory-Y と Technician-Z から構成されます。The manufacture and installation of Smart-X-Widget comprise Factory-Y and Technician-Z using their respective intermediate CA certificates to sign each and every Smart-X-Widgets. このプロセス全体の最終結果は、一意のデバイス証明書を保持する Smart-X-Widget と、Company-X CA 証明書までつながる証明書の信頼チェーンになります。The end result of this entire process is Smart-X-Widgets with unique device certificates and certificate chain of trust going up to Company-X CA certificate.

1 つの会社の証明書から別の会社の証明書への信頼チェーン

ここで、X.509 CA 方式の価値を再検討してみましょう。This is a good point to review the value of the X.509 CA method. Company-X は、Smart-X-Widget ごとに証明書を事前に生成してサプライ チェーンに渡すのではなく、1 回だけ Factory-Y に対して署名するだけです。Instead of pre-generating and handing off certificates for every Smart-X-Widget into the supply chain, Company-X only had to sign Factory-Y once. Company-X は、デバイスのライフ サイクル全体ですべてのデバイスを追跡する必要がなくなる代わりに、サプライ チェーン プロセスから自然に出てくるグループ (ある年の 7 月以降に Technician-Z がインストールしたデバイスなど) でデバイスを追跡および管理できるようになります。Instead of having to track every device throughout the device's life-cycle, Company-X may now track and manage devices through groups that naturally emerge from the supply chain process, for example, devices installed by Technician-Z after July of some year.

最後に大事なこととして、CA 認証方式は、デバイス製造サプライ チェーンに安全なアカウンタビリティを提供します。Last but not least, the CA method of authentication infuses secure accountability into the device manufacturing supply chain. この証明書チェーン プロセスにより、チェーン内の各メンバーのアクションは暗号化によって記録され、検証可能になります。Because of the certificate chain process, the actions of every member in the chain is cryptographically recorded and verifiable.

このプロセスは、特定の前提条件に依存しています。完全を期すために、この前提条件についても説明します。This process relies on certain assumptions that must be surfaced for completeness. これには、デバイスの一意の公開キーと秘密キーのペアを個別に作成し、秘密キーをデバイス内で保護する必要があります。It requires independent creation of device unique public/private key pair and that the private key be protected within the device. さいわいなことに、内部的にキーを生成して秘密キーを保護できる、ハードウェア セキュア モジュール (HSM) 形式の安全なシリコン チップが存在します。Fortunately, secure silicon chips in the form of Hardware Secure Modules (HSM) capable of internally generating keys and protecting private keys exist. Company-X は、Smart-X-Widget の部品表にこの種のチップを 1 つ追加するだけで済みます。Company-X only need to add one of such chips into Smart-X-Widget's component bill of materials.

デバイスの接続Device Connection

ここまでのセクションを考慮したうえで、デバイス接続について説明します。Previous sections above have been building up to device connection. X.509 CA 証明書を IoT Hub に一度登録するだけで、どのように何百万台ものデバイスが接続され、初回から認証されるのでしょうか。By simply registering an X.509 CA certificate to IoT Hub one time, how do potentially millions of devices connect and get authenticated from the first time? 簡単です。既に X.509 CA 証明書の登録で出てきたのと同じ証明書のアップロードと所有証明のフローが使用されます。Simple; through the same certificate upload and proof-of-possession flow we earlier encountered with registering the X.509 CA certificate.

X.509 CA 認証用に製造されたデバイスには、デバイスに一意の証明書と、それぞれの製造サプライ チェーンからの証明書チェーンが用意されています。Devices manufactured for X.509 CA authentication are equipped with device unique certificates and a certificate chain from their respective manufacturing supply chain. デバイスの接続は、初めての場合でも、証明書チェーンのアップロードと所有証明の 2 段階のプロセスで行われます。Device connection, even for the very first time, happens in a two-step process: certificate chain upload and proof-of-possession.

証明書チェーンのアップロード中、デバイスは、デバイスに一意の証明書と共に、デバイスにインストールされている証明書チェーンを IoT Hub にアップロードします。During the certificate chain upload, the device uploads its device unique certificate together with the certificate chain installed within it to IoT Hub. IoT Hub は、事前登録された X.509 CA 証明書を使用して、暗号によっていくつかの確認 (アップロードされた証明書チェーンが内部で一貫性があることと、そのチェーンが X.509 CA 証明書の有効な所有者によって発信されたこと) を行うことができます。Using the pre-registered X.509 CA certificate, IoT Hub can cryptographically validate a couple of things, that the uploaded certificate chain is internally consistent, and that the chain was originated by the valid owner of the X.509 CA certificate. X.509 CA の登録プロセスと同様に、IoT Hub は、所有証明のチャレンジ/応答プロセスを開始して、チェーンを確認し、デバイス証明書がそれを実際にアップロードしたデバイスに属していることを確認します。Just was with the X.509 CA registration process, IoT Hub would initiate a proof-of-possession challenge-response process to ascertain that the chain and hence device certificate actually belongs to the device uploading it. これを行うには、IoT Hub による検証に秘密キーを使用して、デバイスが署名するランダム チャレンジを生成します。It does so by generating a random challenge to be signed by the device using its private key for validation by IoT Hub. 正常な応答により、IoT Hub はデバイスを認証済みとして受け入れ、接続を許可します。A successful response triggers IoT Hub to accept the device as authentic and grant it connection.

この例では、各 Smart-X-Widget は、デバイスに一意の証明書を Factory-Y および Technician-Z の X.509 CA 証明書と共にアップロードした後、IoT Hub からの所有証明チャレンジに応答します。In our example, each Smart-X-Widget would upload its device unique certificate together with Factory-Y and Technician-Z X.509 CA certificates and then respond to the proof-of-possession challenge from IoT Hub.

1 つの証明書から別の証明書へのフロー、ハブからのポップ チャレンジ

信頼の基盤は秘密キー (デバイスの秘密キーを含む) の保護にあることに注意してください。Notice that the foundation of trust rests in protecting private keys including device private keys. したがって、デバイスの秘密キーを保護するためのハードウェア セキュア モジュール (HSM) 形式の安全なシリコン チップと、秘密キーを共有しない (たとえば、工場間では秘密キーを使用して委任しない) というベスト プラクティスはついては、その重要性をいくら強調しても足りません。We therefore cannot stress enough the importance of secure silicon chips in the form of Hardware Secure Modules (HSM) for protecting device private keys, and the overall best practice of never sharing any private keys, like one factory entrusting another with its private key.