ブルートゥース®メッシュ・リモート・プロビジョニング
ブルートゥース®メッシュ・リモート・プロビジョニング
技術概要
| リリース： | 1.0.0 |
| 文書バージョン： | 1.0 |
| 最終更新日： | 2023年9月19日 |
| 著者： |
マーティン・ウーリー、BluetoothSIG |
|
Version |
Date |
Author |
Changes |
|
1.0.0 |
September 19, 2023 |
Martin Woolley, Bluetooth SIG |
Initial version |
|
注 Bluetooth Mesh Profile Specificationは名称が変更され、Bluetooth Meshと呼ばれるようになりました。 プロトコル仕様と呼ばれるようになりました。本書および関連論文では、バージョン1.1仕様に言及する場合はこの名称を使用しますが、バージョン1.0仕様については引き続きBluetooth Mesh プロファイル仕様と呼びます。 |
1.背景
リモート・プロビジョニング機能、ブルートゥース® Meshプロトコル仕様のバージョン1.1で導入されました。その機能と利点を十分に理解するためには、Bluetooth Mesh バージョン 1.0 の特定の側面を理解する必要があります。このセクションでは、この後に続くリモート・プロビジョニングのレビューをサポートするコンテキストと背景を説明します。
1.1 プロビジョニング
デバイスは、プロビジョニングという行為を通じてBluetooth Meshネットワークのメンバー なる。プロビジョニングは、プロビジョナーと呼ばれるデバイスまたはアプリケーション 使用して、コミッショナーによって実行される手順です。 プロビジョナー.デバイスのプロビジョニングにより、デバイスは、ネットワークキー NetKey）およびデバイスのエレメントに割り当てられた一意の連続ユニキャストアドレス範囲など、特定の重要なデータ項目を所有することになる。プロビジョニング中のデバイスは「Provisionee」と呼ばれる。
本来、Bluetooth Meshプロファイル仕様のバージョン1.0で定義されているように、プロビジョナー Provisioneeから直接電波が届く範囲にいなければならない。
1.1.1 プロビジョニング・プロトコル
プロビジョニングの目的のみに使用されるプロトコルは、プロビジョニング・プロトコルと呼ばれます。ブルートゥース® メッシュ・プロファイル仕様のバージョン1.0では、プロトコルには10種類のPDUが含まれていました。
1.1.2 ベアラのプロビジョニング
ブルートゥース® メッシュ バージョン 1.0 では、プロビジョニング・プロトコルはBluetooth LE アドバタイジング・パケットまたは GATT 手順のいずれかをコネクション上で使用して動作可能でした。プロビジョニング・プロトコル PDU のコンテナとしてアドバタイジング・パケットを使用することは、PB-ADV ベアラとして知られています。プロビジョニングに GATT を使用することは、PB-GATT ベアラーと呼ばれる。
1.1.3 プロビジョニングの段階
プロビジョニングは、以下の5つの段階を経て進行する：
- ビーコン送信
- 招待
- 公開鍵の交換
- 認証
- プロビジョニング・データの配布
1.1.3.1ビーコン送信
プロビジョニングの準備が整った新しいデバイスは、そのデバイスがサポートするベアラに応じて、 1 つ又は 2 つのタイプのBluetooth LE 広告パケットをブロードキャストすることにより、その利用可能性を通知する。PB-ADV ベアラがサポートされている場合、未プロビジョニング・デバイス・ビーコンは、 接続不可、スキャン不可の非直接型Bluetooth LE 広告パケットとしてブロードキャストされる。PB-GATT がサポートされている場合、メッシュ・プロビジョニング・サービスのUUID を含む接続可能な広告パケットがブロードキャストされます。両方のベアラがサポートされている場合、これら 2 つの広告形態はインターリーブされます。
いずれの場合も、ビーコン送信 データには、プロビジョニングされていないデバイスのデバイス UUIDが含まれます。デバイス UUID は、物理的またはソフトウェア製品 寿命の間、変化しないデバイスの一意の識別子であり、通常は工場で割り当てられる。
1.1.3.2招待
プロビジョナー 、GATTメッシュ・プロビジョニング・サービスのサポートを示す未プロビジョニング・デバ イスのビーコンおよび/または接続可能な広告をスキャンし、選択された未プロビジョニング・デバ イスとPB-ADVまたはPB-GATTベアラー・インスタンス上でセッション（リンクと呼ばれ る）を確立する。次に、Provisioning Invite PDU を送信して、プロビジョニングプロセスを開始します。Provisionee と呼ばれるようになったデバイスは、プロビジョニングプロセスの次のステッ プを制御するために使用される情報を含む Provisioning Capabilities PDU で応答する。プロビジョナー 、この情報に基づいてコンテンツを含む Provisioning Start PDU を作成し、送信する。
1.1.3.3 公開鍵の交換
楕円曲線暗号（ECC）は、プロビジョナー プロビジョニングされていないデバイスにNetKey 安全に転送するために使用される。ECC は楕円曲線の数学的性質に基づく公開鍵暗号方式である。ECC は比較的小さな鍵サイズを必要とし、計算能力が制限されているデバイスでの使用に適している。
プロビジョナー エフェメラルな公開鍵/秘密鍵ペアを生成し、選択されたベアラを使用して、その公開鍵を Bluetooth リンクを介して被提供者に送信する。被提供者は、同じリンクを介してその公開鍵を送信するか、または、より安全性を高めるために、QR コードを介するか、近距離無線通信（NFC）を使用するなど、帯域外（OOB）の方法を使用してその公開鍵を提供することができる。被提供者の公開鍵/秘密鍵ペアは、静的に定義されている場合もあれば、動的に生成される場合もある。
互いの公開鍵を手に入れたら、鍵合意プロトコルによって共有秘密が計算され、そこからセッション鍵が計算される。セッション鍵は、NetKey 安全な転送に使用される。共有秘密鍵は、認証 ステップで使用される確認鍵や、デバイスキー 計算にも使用される。
1.1.3.4認証
プロビジョニングは、多くのブルートゥース® メッシュデバイスがある場所で行われることがよくあります。プロビジョニングされるデバイスが意図されたものであることを確認し、中間者（MITM）攻撃から保護するために、プロビジョニング手順には認証 ステップが含まれます。
認証はさまざまな形式を取ることができ、プロビジョナー されていないデバイスの能力に応じて選択される。この能力は、招待 ステージで受信した「プロビジョナー 能力」PDUを介してプロビジョナー 通知される。
出力 OOB メソッドでは、プロビジョニングされていないデバイスが、そのデバイスがサ ポートするアクションを使用して数値またはテキスト値を出力します。例えば、LED を点滅させたり、ビープ音を何回も鳴らしたりする。出力された数値はプロビジョナー入力され、確認プロシージャが期待された値が入力されたことをチェックする。
入力OOB方式を使用する場合、プロビジョナー 乱数を生成し、適切なアクション（例えば、ボタンを何回か押す）を使用して未プロビジョニングデバイスに入力され、確認手順によって検証される。
スタティックOOBアプローチでは、固定値を使用する。この固定値は、デバイスまたはそのパッケージに印刷されている可能性があり、プロビジョナー 入力され、確認手順で使用される。
どの方法が使用されたとしても、結果は、プロビジョニングされるデバイスの認証に成功するか失敗するかのいずれかであり、その結果をユーザーに通知する。
1.1.3.5 プロビジョニング・データの配布
認証成功すると、セッション・キーが生成され、リンク経由で送信されるプロビジョニング・データ PDU の暗号化と認証に使用される。プロビジョナー 、プライマリNetKey 、デバイスのエレメント トの一意のアドレス 含むデータを送信する。これでデバイスはプロビジョニングされたと言える。
|
|
図2 - プロビジョニング・プロセスのステージ2～5 |
1.2 デバイスキーとコミッショニングプロセス
ブルートゥース® メッシュ・セキュリティ・システムにはいくつかのセキュリティ・キーがあり、それぞれが特定の役割を担っている。
ネットワークキーは、ネットワークレイヤー関連するPDUのフィールドの 暗号化と認証 使用される。このように使用されることで証明される特定のネットワークキー所有は、そのネットワークキー 属するサブネット ノードのメンバーシップ 意味する。
アプリケーション・キーは、プロトコルスタック 上位レイヤーに関連するPDUのフィールドの暗号化と認証 使用され、一般的に照明や空調など特定のビル・システムの一部であるデバイスに発行されます。
ノードは複数のネットワーク鍵と複数のアプリケーション 鍵を持つことができる。
すべてのノードは1つのデバイスキー デバイスキー）を持っている。このキーは、特定のモデル（通常はデバイス設定に関連する）に属するメッセージを保護するために使用されます。ノードはプロビジョニングされるときに、そのデバイスキー 計算します。デバイスキー ネットワーク上で転送されることはありません。
ブルートゥース® メッシュ・ネットワークが最初に構築される際、特にスマート・ビルディングの世界では、デバイスの設置、プロビジョニング、設定は通常、請負業者のチームによって行われ、最終的に完成したネットワークはビル所有者に引き渡されます。最適なセキュリティのためには、この時点でビル所有者がネットワーク内の各ノードのセキュリティキーを変更できるオプションがあることが望ましい。
Bluetooth Mesh 1.0では、ネットワーク・キーとアプリケーション キーをネットワーク全体で変更できるキー更新 手順が定義されています。Bluetooth Mesh 1.0では、デバイス・キーの変更手順は定義されていません。
1.3 ノードアドレス
ブルートゥース®メッシュにはアドレッシング・スキームがあります。
すべてのエレメントはユニークな16ビットのユニキャスト・アドレス おり、これはすべてのメッセージのソース・アドレス 使われ、時には宛先 アドレス使われる。
グループアドレスとバーチャルアドレスは、ノードの集まりを一つのメッセージでアドレス指定できるようにする2つのタイプのアドレス です。特定のグループアドレス 仮想アドレス 送られたメッセージを受信したり応答したりしたいノードは、そのアドレス 購読 しなければなりません。
元々、Bluetooth Meshのバージョン1.0では、エレメントユニキャスト・アドレス 変更するには、まずプロビジョナー エレメントをネットワークから外し、プロビジョニングをやり直す必要がありました。
1.4 ノードの構成
ノードは論理的な構造を持つ。ノードは1つ以上のエレメントから構成される。エレメント 、デバイスの個別にアドレス指定可能な部分であり、それ自身のユニキャスト・アドレス持つ。ノード内のエレメント アドレスは、エレメント 最も低いアドレス持つように、連続した範囲に割り当てられなければならない。
エレメントには1つ以上のモデルが含まれる。モデルは標準化されたソフトウェア・コンポーネントであり、エレメント 特定の機能（例えば、デバイスのオン・オフや輝度の変更など）を提供する。モデルには、関連する状態と メッセージがあります。ほとんどの場合、ノードとエレメント モデルの関係は、1つのノードが1:nのエレメントを含み、エレメント 1:mのモデルを含む階層構造になっています。しかし、モデルの種類によっては、複数のエレメント所有することもあるため、厳密な階層構造とはなりません。
ノードが持つ要素の具体的な数と、エレメント 含む特定のモデルは、ノードの構 成の一部である。ノードの構成は 構成データ状態で表現される。状態 、その内容をインデックス化されたいくつかのページに分割します。ページ0は重要で、そのノードの現在アクティブな構成データ 含んでいます。
ブルートゥース® メッシュ・バージョン1.0では、ノード・リセットを実行して再プロビジョニングしない限り、ノードの構成を変更することはできませんでした。
1.5 複雑なデバイス
デバイスの中には複雑なものもあり、個々のコンポーネントが多数あり、それぞれがデバイス全体に特化した機能を付加しています。例えば、DALI（デジタル・アドレサブル・ライティング・インターフェイス）デバイスは、通信バスを中心に構築されており、センサーなどの個々のコンポーネントは、このバスに抜き差しすることができる。これらのデバイスは複雑な論理構造を持つ洗練されたものであるだけでなく、コンポーネントの追加や削除が容易であることから、その構成構造は動的である。
2.リモートプロビジョニングについて
リモート・プロビジョニング（RPR）はブルートゥース® メッシュ・プロトコル仕様のバージョン1.1で導入され、プロビジョナー直接電波の届かないメッシュ・ネットワーク上のノードのプロビジョニングと再プロビジョニングを可能にしました。
2.1 能力とメリット
RPRは、3つのトピックに分類される機能と利点を提供する：
2.1.1 マルチホップ・デバイスのプロビジョニング
プロビジョナー 使えば、プロビジョナー プロビジョニングされていないデバイスは、2つのデバイス間のネットワークを介した通信経路が形成されるのであれば、どんな場所にあっても構わない。これにより、多くの実世界の状況において、より実用的なプロセスとなる。
2.1.2 所有者の変更
RPRは、ネットワーク内のデバイスの所有者が変わり、デバイスキー新しい値を設定できるようになったときに役立つ手順を定義している。
2.1.3 動的デバイスの構成
自身の物理的組成の変化を検出することができる複雑なデバイスは、必要なメッシュ組成状態 データ変化を示すことができるようになった。プロビジョナー これを認識してRPR手順を開始し、アクティブな構成データ 状態 更新して新しい構成を反映させることができる。以前は必要であった、デバイスのリセット、再プロビジョニング、再設定はもはや必要ない。
新しいプラグ・アンド・プレイ機能に関連して、メッシュ・プロトコル仕様1.1では、デバイスのライフサイクルとその構造および構成を表す新しい正式名称が導入された。この仕様では、Termの概念を次のように記述している：
|
A 期間とは、ノードの構造（すなわち、機能、エレメント、モデル）およびノードのエレメントのユニキャストアドレスが変更されない、ノードのライフタイム内の期間である。 新しい期間の開始は、補助センサの取り付けなど、物理デバイスのハードウェア構成の変更をサポートするため、または照明器具内ネットワークへの新しいギアの取り付けなど、ノード上のサブシステム構成の変更をサポートするために必要な場合があります。この変更は、ノードが構成データ ページ128（セクション4.2.2.3参照）に入力することで表示され、新しい 期間が開始したときに有効になります。 最初の 期間ネットワーク上のノードの初期期間は、そのノードがネットワーク上にプロビジョニングされた時点から始まります。 A 期間が終了し、新しい タームが開始する。は、ノードアドレス 更新手順またはノード構成更新手順が実行されたときに開始します（セクション3.11.8を参照）。 前期 項ネットワーク上のノードの最後の項は、そのノードがネットワークから取り除かれた時点で終了する。 |
2.2 テクニカル・ハイライト
2.2.1 アーキテクチャ
リモートプロビジョニングには、 クライアント リモートプロビジョニングサーバーモデルの2つの新しいモデルがある。プロビジョナー 、リモートのプロビジョナー されていないデバイスと通信し、プロビジョニングプロセスを制御することを可能にします。このデバイスは PB-Remoteクライアント呼ばれます。クライアント 、モデルメッセージを使用してプロビジョニングプロトコル PDU を送受信する。メッセージは、フラッディング、有向転送、またはこの2つの方法の組み合わせを使用する通常の方法で、ネットワークを介して中継される。リモート・プロビジョニング・サーバー・モデルでは、PB-Remoteクライアント その直接の無線範囲内にあるプロビジョニングされていないデバイスをスキャンし、プロビジョニングすることができます。このモデルを実装したデバイスは、PB-リモートサーバーと呼ばれます。このサーバーモデルは、デバイスキー またはプラグアンドプレイデバイスの構成を変更するために必要な手順を実行することもサポートします。
リモート・プロビジョニングは、PB-Remote プロビジョニング・ベアラも定義する。PB-Remote ベアラは、PB-ADV または PB-GATT を使用して、PB-Remote サーバー装置に実装されている場合、プロビジョニングされていないデバイスと通信します。PB-Remoteサーバ機器に実装されている場合、このベアラは、プロビジョナー 参加しているリモート機器との通信を可能にします。
ノード・プロビジョニング・プロトコル・インターフェイスとして知られるインターフェイスが定義され、これにより、デバイスキー 変更やプラグアンドプレイ・デバイスの設定など、多くの重要な新しい手順が可能になる。
リモート・プロビジョニング・モデルは、以下のメッセージを定義している：
- プロビジョニングが可能で、PB-Remote Serverから直接電波の届く範囲にあるデバイスを、ネットワーク上のどこからでも検出できるようにします。
- PB-リモートサーバーと、選択されたプロビジョニングされていないノードとの間でリンクを確立できるようにする。
- プロビジョニングプロトコルのPDUをカプセル化し、クライアント サーバーの間でどちらかの方向に転送できるようにする。
- サーバーとして機能するノードのデバイスキー保護される。
- ノードプロビジョニングプロトコルインタフェース手順に関する。
概要では、リモート・プロビジョニングは、PB-リモート・サーバーが、PB-リモート・クライアント要求に応じて、選択されたプロビジョニングされていないデバイスへのリンクを確立することによって機能する。次に、リモート・プロビジョニング・メッセージ内にカプセル化されたプロビジョニング・プロトコルPDUを受信し、それらのPDUを抽出してリンク上に送信し、その応答としてプロビジョニング・プロトコルPDUを受信し、それを他のリモート・プロビジョニング・メッセージ内にカプセル化してPB-リモートクライアント送り返します。図3を参照。
このようにして、PB-Remoteクライアント リモートのプロビジョニングされていないデバイスと通常のプロビジョニング・プロセスを実行します。PB-Remoteサーバは、ベアラ間の変換と、クライアント 未プロビジョニング・デバイスに送信されるPB-Remoteメッセージ内のプロビジョ ニングPDUの転送により、プロセス内の仲介役として機能します。
図3 - リモート・プロビジョニングのアーキテクチャ
2.2.2 リモートプロビジョニングの段階
リモート・プロビジョニングは、以下の4つの段階を通過すると考えることができる：
- リモート・スキャンの実行
- プロビジョニングされていないデバイスへのリンクを開く
- デバイスのプロビジョニング
- リンクを閉じる
2.2.2.1 リモート・スキャン
図4 - リモートプロビジョニングスキャンの手順
PB-Remoteクライアント、リモートプロビジョニングスキャン開始またはリモートプロビジョニング拡張スキャン開始の 2 種類のリモートスキャンを要求できます。図 4 を参照してください。
2.2.2.1.1 リモートプロビジョニングスキャン手順
リモートプロビジョニングスキャン開始メッセージは、PB-リモートサーバーのユニキャスト宛先 アドレス 送信され、プロビジョニング可能なデバイスのスキャンを開始するように指示します。このメッセージには、デバイスUUIDが含まれている場合は、特定のデバイスのみをスキャンすることを示す。あるいは、PB-Remote Serverの範囲内にあるすべてのプロビジョニングされていないデバイスがスキャンされます。この2つのオプションはそれぞれ、単一デバイススキャン、複数デバイススキャンと呼ばれる。
リモートプロビジョニングスキャン開始は 承認済みメッセージ であり、PB-リモートサーバーノードはリモートプロビジョニングスキャンステータスメッセージで応答します。
リモート・プロビジョニング・スキャン・レポート・メッセージは、PB-リモート・サーバーからスキャンを開始したPB-リモート・クライアント 送信されます。これらのメッセージには、サーバーがプロビジョニング可能な未プロビジョニングの各デバイスの詳細が含まれ、識別デバイスのUUID、デバイスの帯域外（OOB）認証 機能に関する情報、PB-Remoteサーバーが測定した信号強度（RSSI）、およびプロビジョニング対象のデバイスからURIハッシュ値（利用可能な場合）が含まれます。シングル・デバイス・スキャンでは、指定されたデバイス UUID のみのスキャン・レポート・メッセージが生成されます（デバイスが検出された場合）。
2.2.2.1.2 リモートプロビジョニング拡張スキャン手順
このリモート・スキャンのバリエーションにより、PB-リモート・クライアント 、（PB-ADV の場合）プロビジョニングされていないデバイス・ビーコンや（PB-GATT の場合）接続可能な広告パケットのサービス・データ AD タイプにはない、単一デバイスに関する特定の追加情報を要求することができます。関心のある追加情報は、ブルートゥース® LE スキャン・レスポンス・パケット又は同じデバイスの代替コンテン ツを含む追加広告パケットで利用可能である。
拡張スキャンでは、単一のプロビジョニングされていないデバイス、またはPB-Remote Serverノード自体から情報を取得することができます。これらのシナリオのうち最初のシナリオでは、リモートプロビジョニング拡張スキャン手順は単一のデバイスに対してのみ実行されますが、PB-Remote Serverの実装がそれをサポートしている場合は、各々が異なるデバイスUUIDをターゲットとする手順の複数のインスタンスを同時に実行することができます。
PB-Remoteクライアント送信するRemote Provisioning Extended Scan Startメッセージは、指定されたユニキャスト・アドレス持つ PB-Remote Server ノードによるリモート拡張スキャンを開始します。このメッセージには、値が要求される AD タイプのリストを含めることができます（Bluetooth Mesh プロトコル仕様に記載されているいくつかの制限に従います）。メッセージに Device UUID が含まれている場合は、指定されたプロビジョニングされていないデバイスのスキャンが実行され、そうでない場合は PB-Remote Server ノード自身から情報が取得されます。
リモートプロビジョニング拡張スキャンスタートは 未確認メッセージです。
リモートプロビジョニング拡張スキャンレポートメッセージは、拡張スキャンを開始したPB-Remoteクライアント サーバーから返送され、PB-Remoteサーバーによって取得された要求されたタイプの情報が含まれます。
2.2.2.2 リンクを開く
図 5 - プロビジョニングされていないデバイスへのリモート・リンクを開く
PB-Remoteクライアント Device UUIDパラメータ 指定してRemote Provisioning Link Openメッセージを送信すると、PB-Remote Server ノードは指定されたデバイスとのプロビジョニング・リンクの確立を要求できます。これは承認済みメッセージ であり、その結果、サーバーはリモート・プロビジョニング・リンク・ステータス・メッセージを クライアント送り返します。図 5 を参照してください。
リモートプロビジョニングリンクオープンメッセージは、新しいノードプロビジョニングプロトコルインタフェース（2.2.3参照）を介して利用可能な他の手順のために、PB-リモートサーバーを準備するために使用することができることに注意してください。
2.2.2.3 デバイスのプロビジョニング
図6 - リモート・プロビジョニング
PB-Remote サーバーノードとターゲット未プロビジョニングデバイス間のリンクが確立されると、PB-Remoteクライアント はプロビジョニングプロセス自体を進行させることができる。このプロセスは、必要な Provisioning Protocol PDU がRemote Provisioning PDU Sendメッセージと呼ばれる PB-Remote メッセージタイプ内にカプセル化される点を除き、1.1.3.2 から 1.1.3.5 で説明した 4 つのステージと基本的に同じである。サーバーは、PB-Remote メッセージから Provisioning Protocol PDU を抽出し、リンクを介して未プロビジョニングデバイスに転送します。未プロビジョニングデバイスから PB-Remote サーバーに送信された Provisioning Protocol PDU は、Remote Provisioning PDU Reportメッセージにカプセル化されて PB-Remoteクライアント 送り返されます。図 6 を参照してください。
2.2.2.4 リンクを閉じる
図 7 - リモートプロビジョニングリンクを閉じる
プロビジョニングが完了すると、PB-Remoteクライアント PB-Remote サーバーに、プロビジョニングされたデバイスへのリンクを閉じるように指示します。これは、Remote Provisioning Link Closeメッセージを送信し、サーバーがRemote Provisioning Link Statusメッセージで応答することで実現されます。
2.2.3 ノードプロビジョニングプロトコルインタフェース
PB-Remoteでは、NPPI（Node Provisioning Protocol Interface）と呼ばれる新しく定義されたインタフェースを介して利用可能な一連の手順を定義しています。リモートプロビジョニングサーバーモデルをサポートするノードは、NPPI インターフェースとそれに関連する手順をサポートする必要があります。NPPI 手順は、クライアント 、必要な NPPI 手順を示す NPPI 手順フィールドを含むリモート・プロビジョニング・リンク・オープン・メッセージを送信することで開始できます。NPPI 手順は、リモートプロビジョニングサーバーモデルによって実行される。
ノードプロビジョニングプロトコルインターフェースは、リモートプロビジョニングサーバーモデルが、リモートプロビジョニングサーバーモデル自身を宛先とするリモートプロビジョニングリンクオープンメッセージを受信するまで閉じている。インターフェイスが開かれている場合、プロビジョニングプロトコル PDU は、リモートプロビジョニングメッセージ内にカプセル化された通常のフロー（ただし、プロビジョニングデータ PDU の値にはいくつかの制約がある）に従って交換される。これらの PDU は、リモート Provisioning Server モデルによって処理され、選択された手順が実行される。これは、図 5、6、および 7 に示すように、プロビジョニングプロトコル PDU がリンクを介してプロビジョニングされていないデバイスに転送される、2.2.2.3 で説明した動作とは対照的であることに注意すること。
図8 - NPPIアーキテクチャ
Bluetooth Mesh 1.1 プロトコル仕様で定義されている NPPI 手順は以下の通りです。
2.2.3.1デバイスキー リフレッシュ
この手順により、ノードを完全に再プロビジョニングすることなく、新しいデバイスキー ノードに割り当てることができます。ノードのエレメント アドレスやNetKeysとAppKeysのリストなど、既存のデータは影響を受けません。
この手順は、標準的なプロビジョニング・プロトコルと手順を使用して計算され る、デバイスキー Candidateと呼ばれる新しい候補鍵で、2段階にわたって実行される。この鍵がデバイスから離れることはなく、楕円曲線暗号に基づくDiffie-Hellman鍵合意プロトコルが、Configuration Managerがそのコピーを安全に所有できるようにするために使用される。これにより、この手順に関連するセキュリティは、デバイスの最初のプロビジョニング時と同じレベルになります。この段階では、ノードのデバイスキー 変更されていないが、新しいキー値の候補が ノードに知られている。ステージ2では、新しいデバイスキー 候補を使用して暗号化されたアクセス メッセージ受信すると、デバイスキー 候補がノードの新しいデバイスキー なる。これは、新しい鍵が使用中であることを示す。この時点で、古い鍵は破棄され、新しい候補デバイスキー その代わりとなる。
2.2.3.2アドレス リフレッシュ
ノードアドレス リフレッシュ手順では、ノードのユニキャスト・アドレス そのデバイスキー 、リセットして再プロビジョニングすることなく変更できます。ノードのネットキーやAppKeyのリストなどの既存のデータは影響を受けません。エレメント 、エレメント割り当てられた新しいユニキャスト・アドレス 始まる、連続した範囲を形成するアドレス 割り当てられます。
2.2.3.3 ノード構成のリフレッシュ
この手順により、ノードの構成（要素やモデルの数）を変更することができ、物理的な構成構造が動的な複雑なデバイスにプラグアンドプレイ機能を提供することができる。
ネットワーク内のDALIデバイスを想像してみてください。このデバイスは洗練された照明製品 、その内部バスは最大128の異なるコンポーネントを収容することができます。例えば、様々な種類のセンサーがノードに差し込まれたり、抜かれたりします。この種のデバイスは、適切なファームウェアでプログラムされると、これらのタイプの変化を検出することができます。
このNPPI手順は、その物理的構成の変更を検出したノードが、構成データ 状態ページ128に詳細を書き込むことを要求する。PB-クライアント開始されるこの手順は、最終的に、新しい構成状態 データがページ128から、アクティブな構成状態 データが格納されているページ0にコピーされ、必要な変更をもたらす。
この手続きが実行されると、新しいデバイスキー ノードに割り当てられる。この手続きによって構成データ 状態 更新されるが、他の状態は変更されない。
2.2.4 リモートプロビジョニングとセキュリティ
図9は、リモート・プロビジョニングのセキュリティ保護方法を示している。PB-Remoteクライアント サーバーが交換するメッセージは、PB-Remote サー バーノードのデバイスキー 使用して保護される。その後実行されるプロビジョニング手順は、1.1.3 節で説明される通常のプロビジョニング手順のステージ 2 ～ 5 を通過し、標準的なプロビジョニング・セキュリティを使用する。
図 9 - リモート・プロビジョニング・セキュリティ
デバイスがサポートする可能性のある認証 方法の中には、ユーザがデバイスを見たり、聞いたり、触れたりできることに依存しているものがある。リモート・プロビジョニングは、プロビジョナーかなり離れた場所にあるデバイスのプロビジョニングを可能にするように設計されているため、これらのタイプの認証 方法は、状況によっては最適でなかったり、実用的でなかったりする場合があります。幸いなことに、ブルートゥース® メッシュ・バージョン1.1には、証明書ベースのプロビジョニングと呼ばれる、デバイスの見通し外のリモート・プロビジョニングに最適な新しい認証 アプローチも追加された。この機能 、「証明書ベースのプロビジョニング技術概要」を参照してください。
2.2.5 バルク・プロビジョニング
ブルートゥース® メッシュ1.0は、プロビジョナー際に新しいデバイスの電波の届く範囲に直接いる必要があるため、プロビジョナー再配置することなく、大規模なデバイスのコレクション、おそらくネットワーク内のすべてのデバイスのプロビジョニングには適していませんでした。
リモート・プロビジョニングは、証明書ベースのプロビジョニングと組み合わせると、コミッショナーによって開始される単一の手順で、新しいネットワーク内のすべてのデバイスをプログラム的にプロビジョニングするために使用できるプロビジョニング・ツールの可能性を提供する。
3.閉じる
ブルートゥース® メッシュのリモート・プロビジョニング機能 、ネットワークへの新しいデバイスのプロビジョニングがより簡単になりました。新しいノード・プロビジョニング・プロトコルのインターフェイス手順は、実際のユースケースを反映し、新しいネットワークの確立や複雑なデバイスの保守に関わる通常のワークフローを確実にサポートします。
