Azure IoT デバイス製造元向けのセキュリティ プラクティス

  • [アーティクル]

IoT デバイスをリリースする製造元が増えており、一般的なプラクティスに関するガイダンスを示しておくと役に立ちます。 この記事では、Azure IoT Device Provisioning Service (DPS) で使用するデバイスを製造するときに考慮すべき推奨されるセキュリティ プラクティスについて説明します。

  • デバイス認証オプションの選択
  • IoT デバイスへの証明書のインストール
  • 製造プロセスへのトラステッド プラットフォーム モジュール (TPM) の統合

デバイス認証オプションの選択

IoT デバイスのセキュリティ対策の最終的な目的は、セキュリティで保護された IoT ソリューションを作成することです。 ただし、ハードウェアの制限、コスト、セキュリティの専門知識のレベルなどの問題はすべて、選択するオプションに影響します。 さらに、セキュリティに対するアプローチは、IoT デバイスをクラウドに接続する方法に影響します。 考慮すべき IoT セキュリティの要素はいくつかありますが、すべてのお客様が直面する重要な要素は、使用する認証の種類です。

広く使用されている 3 種類の認証は、X.509 証明書、トラステッド プラットフォーム モジュール (TPM)、および対称キーです。 認証の種類は他にもありますが、Azure IoT でソリューションを構築するほとんどのお客様は、これら 3 種類のいずれかを使用します。 この記事の残りの部分では、各認証の種類を使用する長所と短所について説明します。

X.509 証明書

X.509 証明書は、認証に使用できるデジタル ID の一種です。 X.509 証明書の規格は、IETF RFC 5280 に記載されています。 Azure IoT には、証明書を認証する方法が 2 つあります。

  • サムプリント。 サムプリント アルゴリズムは証明書で実行され、16 進数の文字列が生成されます。 生成される文字列は、証明書に対する一意の識別子です。
  • 完全なチェーンに基づく CA 認証。 証明書チェーンは、エンド エンティティ (EE) 証明書を認証するために必要なすべての証明書の階層リストです。 EE 証明書を認証するには、信頼されたルート CA を含む、チェーン内の各証明書の認証を行う必要があります。

X.509 の長所:

  • X.509 は、Azure IoT でサポートされている最も安全な認証の種類です。
  • X.509 を使用すると、証明書を管理するための高レベルの制御が可能になります。
  • X.509 ベースの認証ソリューションを提供するために、多くのベンダーを利用できます。

X.509 の短所:

  • 多くのお客様は、証明書を外部のベンダーに依存する必要があります。
  • 証明書の管理にはコストがかかる可能性があり、ソリューションの総コストも増加します。
  • ロジスティクスが十分に考慮されていない場合、証明書のライフサイクル管理が困難になることがあります。

トラステッド プラットフォーム モジュール (TPM)

TPM (ISO/IEC 11889 とも呼ばれます) は、暗号化キーを安全に生成して格納するための標準です。 TPM には、標準を実装するモジュールと対話する仮想または物理 I/O デバイスも含まれます。 TPM デバイスは、個別のハードウェア、統合されたハードウェア、ファームウェアベースのモジュール、またはソフトウェアベースのモジュールとして存在できます。

TPM と対称キーには、次の 2 つの重要な違いがあります。

  • TPM チップでは、X.509 証明書を格納することもできます。
  • DPS での TPM の構成証明には、非対称認証の一形式である TPM 保証キー (EK) が使用されます。 非対称認証では、暗号化には公開キーが使用され、復号化には別の秘密キーが使用されます。 それに対し、対称キーでは対称認証が使用され、秘密キーが暗号化と復号化の両方に使用されます。

TPM の長所:

  • TPM は、多くの Windows デバイスに標準ハードウェアとして含まれており、オペレーティング システムのための組み込みサポートがあります。
  • TPM の構成証明は、Shared Access Signature (SAS) トークン ベースの対称キーの構成証明より、セキュリティ保護が簡単です。
  • デバイスの資格情報の有効期限切れ、更新、ロールを簡単に行うことができます。 TPM デバイスの再プロビジョニング期限になると常に、DPS によって IoT Hub の資格情報が自動的にロールされます。

TPM の短所:

  • TPM は複雑であり、使用するのが困難な場合があります。
  • 物理的な TPM または品質エミュレーターを使用しない限り、TPM でのアプリケーション開発は困難です。
  • ハードウェアに TPM を組み込むために、デバイスのボードの再設計が必要になる場合があります。
  • EK を TPM にロールする場合は、TPM の ID を破棄して新しいものを作成します。 物理チップは同じままですが、IoT ソリューションの ID は新しくなります。

対称キー

対称キーでは、メッセージの暗号化と復号化に同じキーが使用されます。 その結果、デバイスと、それを認証するサービスの両方で、同じキーが認識されます。 Azure IoT では、SAS トークン ベースの対称キー接続がサポートされています。 対称キー認証を使用すると、キーをセキュリティで保護し、X.509 認証で同等のセキュリティ レベルを実現するために、所有者に大きな責任が要求されます。 対称キーを使用する場合は、ハードウェア セキュリティ モジュール (HSM) を使用してキーを保護することをお勧めします。

対称キーの長所:

  • 対称キーは、認証を始めるのに最も簡単かつ低コストな方法です。
  • 対称キーを使用すると、新しく生成するものがないため、プロセスが簡素化されます。

対称キーの短所:

  • 対称キーをセキュリティで保護するには、かなりの労力を必要とします。 同じキーがデバイスとクラウドの間で共有されるため、キーを 2 か所で保護する必要があります。 これに対し、TPM と X.509 証明書での問題は、秘密キーを開示することなく公開キーを所有していることを証明することです。
  • 対称キーを使用すると、簡単に問題のあるセキュリティ プラクティスが実施される可能性があります。 対称キーでは、暗号化されていないキーがデバイスにハード コーディングされることがよくあります。 この方法は便利ですが、キーが脆弱になります。 対称キーをデバイスに安全に格納することによって、リスクをある程度軽減できます。 ただし、利便性より最終的なセキュリティが優先される場合は、X.509 証明書または TPM を認証に使用する必要があります。

共有対称キー

対称キー認証には、共有対称キーと呼ばれるバリエーションがあります。 この方法では、すべてのデバイスで同じ対称キーが使用されます。 デバイスでは共有対称キーを使用しないことをお勧めします。

共有対称キーの長所:

  • 実装が簡単で、大規模に作成しても低コストです。

共有対称キーの短所:

  • 攻撃に対して非常に脆弱です。 簡単な実装の利点より、リスクの方が大きく上回ります。
  • 共有キーを取得すると、だれでもデバイスを偽装できます。
  • 侵害された共有対称キーを使用すると、デバイスの制御が失われる可能性があります。

デバイスの適切な選択

認証方法を選択するには、独自の製造プロセスに対する各アプローチの利点とコストを考慮してください。 デバイス認証の場合、通常、特定の方法の安全性と便利さの間には、逆の関係があります。

IoT デバイスへの証明書のインストール

このセクションでは、X.509 証明書を使用して IoT デバイスの認証を行う場合に、製造プロセスに証明書を統合する方法についてのガイダンスを示します。 いくつかのことを決定する必要があります。 これには、一般的な証明書変数、証明書を生成するタイミング、および証明書をインストールするタイミングに関する決定が含まれます。

パスワードを使い慣れている場合、すべてのデバイスで同じパスワードを使用できるのと同じように、すべてのデバイスで同じ証明書を使用できないのはなぜか、疑問に思うかもしれません。 まず、すべての場所で同じパスワードを使用するのは危険です。 そのような慣習により、数年前に米国東部海岸で DNS がダウンした事例など、企業は大きな DDoS 攻撃を受けています。 個人アカウントであっても、すべての場所で同じパスワードを使用しないでください。 第 2 に、証明書はパスワードではなく、一意の ID です。 パスワードは、セキュリティで保護された建物のドアを開けるために使用できる秘密のコードのようなものです。 それは知っていることであり、だれにでもパスワードを教えて入館させることができます。 証明書は、写真と他の詳細が含まれる運転免許証に似ており、守衛にそれを提示することで、保護された建物に入ることができます。 それは、所持者の身元と関連付けられています。 守衛によって所持者が運転免許証と正確に照合された場合、所持者だけが自分のライセンス (ID) を使用して中に入ることができます。

証明書の決定に含まれる変数

次の変数と、それぞれが製造プロセス全体に与える影響を検討します。

証明書の信頼のルートの提供元

公開キー基盤 (PKI) の管理は、コストがかかり、複雑な場合があります。 企業に PKI の管理経験がない場合は特にそうです。 オプションは次のとおりです。

  • サードパーティの PKI を使用します。 サードパーティの証明書ベンダーから、中間署名証明書を購入できます。 または、プライベート証明機関 (CA) を使用することもできます。
  • 自己管理型の PKI を使用します。 独自の PKI システムを維持し、独自の証明書を生成することができます。
  • Azure Sphere セキュリティ サービスを使用します。 このオプションは、Azure Sphere デバイスにのみ適用されます。

証明書を格納する場所

証明書の格納場所の決定に影響を与える要因がいくつかあります。 そのような要因としては、デバイスの種類、予想される利益の余裕 (安全なストレージを用意する余裕があるかどうか)、デバイスの機能、使用できるデバイスでの既存のセキュリティ テクノロジなどがあります。 次のオプションを検討してください。

  • ハードウェア セキュリティ モジュール (HSM)。 HSM を使用することを強くお勧めします。 お使いのデバイスの制御基板に HSM が既に取り付けられているかどうかを確認します。 HSM がないことがわかったら、ハードウェアの製造元に問い合わせて、ニーズを満たす HSM を特定します。
  • 信頼できる実行環境 (TEE) など、ディスク上のセキュリティで保護された場所。
  • ローカル ファイル システムまたは証明書ストア。 Windows 証明書ストアなど。

工場での接続性

デバイスにインストールする証明書を取得する方法とタイミングは、工場での接続性によって決まります。 次のような接続性オプションがあります。

  • 接続あり。 接続が最適であれば、証明書をローカルに生成するプロセスが簡素化されます。
  • 接続なし。 この場合、CA からの署名入り証明書を使用して、ローカルにオフラインでデバイス証明書を生成します。
  • 接続なし。 この場合、事前に生成された証明書を取得できます。 または、オフライン PKI を使用して、ローカルで証明書を生成することもできます。

監査要件

製造するデバイスの種類によっては、デバイスにデバイス ID がインストールされる方法についての監査証跡を作成する規制要件が適用される場合があります。 監査を組み込むと、製造コストが大幅に増加します。 そのため、ほとんどの場合は、必要な場合にのみ行います。 監査が必要かどうかわからない場合は、会社の法務部門に確認してください。 監査オプションは次のとおりです。

  • 機密関連の業界ではない場合。 監査は必要ありません。
  • 機密関連の業界である場合。 コンプライアンス認定要件に従って、セキュリティで保護された場所に証明書をインストールする必要があります。 証明書をインストールするためのセキュリティで保護された場所が必要な場合は、デバイスに証明書をインストールする方法は既にわかっているものと考えられます。 また、おそらく、監査システムは既に配置されています。

証明書の有効期間の長さ

運転免許証と同様に、証明書には作成時に有効期限が設定されます。 証明書の有効期間の長さのオプションは次のとおりです。

  • 更新不要。 この方法では、長い更新期間が使用されるため、デバイスの有効期間中に証明書を更新する必要はありません。 このようなアプローチは便利ですが、リスクもあります。 デバイスで HSM などの安全なストレージを使用することにより、リスクを軽減することができます。 ただし、有効期間が長い証明書は使用しないことをお勧めします。
  • 更新必要。 デバイスの有効期間中に、証明書を更新する必要があります。 証明書の有効期間の長さはコンテキストによって異なり、更新の戦略が必要になります。 この戦略には、証明書を取得する場所と、デバイスが更新プロセスで使用する必要のある無線機能の種類を含める必要があります。

証明書を生成するタイミング

工場でのインターネット接続機能は、証明書を生成するプロセスに影響します。 証明書を生成するタイミングには、いくつかのオプションがあります。

  • 事前に読み込まれた証明書。 一部の HSM ベンダーからは、顧客のために HSM ベンダーが証明書をインストールするプレミアム サービスが提供されています。 顧客は、まず、HSM ベンダーが署名証明書にアクセスできるようにします。 その後、その署名証明書によって署名された証明書が、HSM ベンダーによって、顧客が購入した各 HSM にインストールされます。 顧客が行う必要があるのは、デバイスに HSM を取り付けることだけです。 このサービスにはコストがかかりますが、製造プロセスを効率化するのに役立ちます。 また、証明書をいつインストールすべきかという問題も解決されます。
  • デバイスによって生成された証明書。 デバイスで内部的に証明書が生成される場合は、デバイスからパブリック X.509 証明書を抽出して、DPS に登録する必要があります。
  • 接続されている工場。 工場が接続されている場合は、必要なときにいつでもデバイス証明書を生成できます。
  • オフラインの工場と独自の PKI。 工場が接続されておらず、オフライン サポートで独自の PKI を使用している場合は、必要なときに証明書を生成できます。
  • オフラインの工場とサードパーティの PKI。 工場が接続されておらず、サードパーティの PKI を使用している場合は、事前に証明書を生成する必要があります。 また、接続されている場所から証明書を生成する必要があります。

証明書をインストールするタイミング

IoT デバイス用の証明書を生成した後は、それらをデバイスにインストールできます。

事前に読み込まれた証明書を HSM で使用する場合は、プロセスが簡略化されます。 デバイスに HSM をインストールした後は、デバイスのコードでそれにアクセスできます。 その後、HSM API を呼び出して、HSM に格納されている証明書にアクセスします。 製造プロセスに対しては、この方法が最も適しています。

事前に読み込まれた証明書を使用しない場合は、製造プロセスの一部として証明書をインストールする必要があります。 最も簡単な方法は、初期ファームウェア イメージをフラッシュするのと同時に、HSM に証明書をインストールすることです。 プロセスでは、各デバイスにイメージをインストールするステップを追加する必要があります。 このステップの後、デバイスを梱包して出荷する前に、最終的な品質チェックとその他の手順を実行できます。

インストール プロセスと最終的な品質チェックを 1 つのステップで実行できるソフトウェア ツールが用意されています。 これらのツールを変更して、証明書を生成したり、事前に生成された証明書ストアから証明書を取得したりすることができます。 その後、ソフトウェアで、インストールする必要がある場所に証明書をインストールできます。 この種のソフトウェア ツールを使用すると、運用品質の製造を大規模に実行できます。

デバイスに証明書をインストールしたら、次のステップでは、DPS にデバイスを登録する方法を学習します。

製造プロセスへの TPM の統合

このセクションでは、TPM を使用して IoT デバイスを認証する場合のガイダンスを提供します。 このガイダンスでは、ハッシュベースのメッセージ認証コード (HMAC) キーをサポートする、広く使用されている TPM 2.0 デバイスについて説明します。 TPM チップに対する TPM の仕様は、Trusted Computing Group によって管理されている ISO 標準です。 TPM の詳細については、TPM 2.0 および ISO/IEC 11889 の仕様を参照してください。

TPM の所有権の取得

TPM チップ搭載デバイスの製造における重要な手順は、TPM の所有権を取得することです。 この手順は、デバイスの所有者にキーを提供できるようにするために必要です。 最初のステップでは、デバイスから保証キー (EK) を抽出します。 次のステップでは、実際に所有権を要求します。 これを行う方法は、使用している TPM とオペレーティング システムによって異なります。 必要に応じて、TPM の製造元またはデバイスのオペレーティング システムの開発元に問い合わせて、所有権を要求する方法を確認します。

製造プロセスでは、EK の抽出と所有権の要求を異なるタイミングで行うことにより、柔軟性を高めることができます。 多くの製造元では、ハードウェア セキュリティ モジュール (HSM) を追加してデバイスのセキュリティを強化することで、この柔軟性が利用されています。 ここでは、EK を抽出するタイミング、TPM の所有権を要求するタイミング、およびこれらの手順を製造タイムラインに統合するときの考慮事項について説明します。

重要

以下のガイダンスでは、個別の TPM、ファームウェア TPM、または統合された TPM を使用しているものとします。 ガイダンスの該当する箇所には、非個別 TPM またはソフトウェア TPM の使用に関する注意事項が記載されています。 ソフトウェア TPM を使用する場合は、このガイダンスに含まれていない追加の手順が存在する可能性があります。 ソフトウェア TPM には、この記事では書ききれないさまざまな実装があります。 一般に、ソフトウェア TPM は、次の一般的な製造タイムラインに統合することができます。 ただし、プロトタイプの作成やテストにはソフトウェアでエミュレートされた TPM が適していますが、個別 TPM、ファームウェア TPM、または統合 TPM と同じレベルのセキュリティを提供することはできません。 一般的な方法として、運用環境ではソフトウェア TPM を使用しないでください。

一般的な製造タイムライン

次のタイムラインでは、TPM が製造プロセスを経てデバイスになるまでの過程を示します。 各製造プロセスは個々に異なり、このタイムラインでは最も一般的なパターンが示されています。 タイムラインでは、キーを使用して特定のアクションを実行するタイミングに関するガイダンスを提供します。

手順 1: TPM が製造される

  • デバイスで使用するために TPM を製造元から購入した場合は、公開保証キー (EK_pubs) を抽出してもらえるかどうかを確認します。 出荷するデバイスで使用できる EK_pubs の一覧を製造元から提供されると便利です。

    Note

    プロビジョニング サービスの共有アクセス ポリシーを使用して、TPM の製造元に、登録リストへの書き込みアクセス権を付与することができます。 この方法を使用すると、製造元が登録リストに TPM を追加できます。 ただし、それは製造プロセスの早い段階であり、TPM 製造元の信頼が必要です。 ご自身の責任で行ってください。

  • デバイスの製造元に販売する TPM を製造する場合は、物理的な TPM と共に EK_pubs の一覧を顧客に提供することを検討します。 顧客に EK_pubs を提供すると、顧客のプロセスで手間が省かれます。

  • 独自のデバイスで使用する TPM を製造する場合は、プロセス内で EK_pub を抽出するのに最も適したポイントを特定します。 タイムラインの残りの任意のポイントで EK_pub を抽出できます。

手順 2: TPM がデバイスにインストールされる

製造プロセスのこのポイントでは、デバイスで使用される DPS インスタンスを把握しておく必要があります。 その結果、自動プロビジョニングのための登録リストにデバイスを追加できます。 自動デバイス プロビジョニングの詳細については、DPS のドキュメントを参照してください。

  • EK_pub を抽出していない場合は、ここがそれを行うのに適したタイミングです。
  • TPM のインストール プロセスによっては、この手順は TPM の所有権を取得するのにも適しています。

手順 3: デバイスにファームウェアとソフトウェアがインストールされる

プロセスのこのポイントで、プロビジョニング用の ID スコープとグローバル URL と共に、DPS クライアントをインストールします。

  • ここが、EK_pub を抽出する最後の機会です。 サードパーティによってデバイスにソフトウェアがインストールされる場合は、最初に EK_pub を抽出することをお勧めします。
  • 製造プロセスのこのポイントは、TPM の所有権を取得するのに最適です。

    Note

    ソフトウェア TPM を使用している場合は、今すぐインストールできます。 同時に EK_pub を抽出します。

手順 4: デバイスが梱包され、倉庫に送られる

デバイスは、DPS によって展開およびプロビジョニングされるまで、最長で 1 年間倉庫に保管されていることがあります。 デバイスが展開前に倉庫に長期間保管されていた場合、デバイスを展開するお客様は、ファームウェア、ソフトウェア、または期限切れの資格情報の更新が必要になることがあります。

手順 5: デバイスが使用場所に設置される

デバイスが最終的な場所に到着すると、DPS による自動プロビジョニングが行われます。

詳細については、「プロビジョニング」および「TPM の構成証明」を参照してください。

リソース

この記事で推奨されているセキュリティ プラクティスに加えて、Azure IoT では、セキュリティで保護されたハードウェアの選択とセキュリティで保護された IoT デプロイの作成に役立つリソースが提供されています。