ブルートゥース®メッシュ・リモート・プロビジョニング
ブルートゥース®メッシュ・リモート・プロビジョニング
技術概要
| リリース： | 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ネットワークのメンバー なります。プロビジョニングは、コミッショナーが Provisionerと呼ばれるデバイスまたはアプリケーション 使用して実行する手順です。デバイスをプロビジョニングすると、ネットワークのプライマリネットワークキー（NetKey）や、デバイスのエレメントに割り当てられた連続したユニキャストアドレスの一意の範囲など、特定の重要なデータ項目がデバイスに付与されます。プロビジョニング中のデバイスはProvisionee と呼ばれる。
本来、Bluetooth Meshプロファイル仕様のバージョン1.0で定義されているように、Provisionerは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 招待
Provisioner は、GATT メッシュ・プロビジョニング・サービスに対応していることを示す未プロビジョニングデバイスのビーコンおよび／または接続可能な広告をスキャンし、選択された未プロビジョニングデバイスとの PB-ADV または PB-GATT ベアラインスタンス上のセッション（リンクと呼ばれる）を確立する。次に、Provisioning Invite PDU を送信して、プロビジョニングプロセスを開始します。Provisionee と呼ばれるこのデバイスは、Provisioning Capabilities PDU で応答します。この Provisioning Capabilities PDU には、プロビジョニングプロセスの次のステップを制御するために使用される情報が含まれています。Provisioner は、この情報に基づいて Provisioning Start PDU を作成し、送信する。
1.1.3.3 公開鍵の交換
ECC（Elliptic Curve Cryptography：楕円曲線暗号）は、NetKey を Provisioner から Provision されていないデバイスに安全に転送するために使用されます。ECC は、楕円曲線の数学的特性に基づく公開鍵暗号のアプローチである。ECC は、楕円曲線の数学的性質に基づく公開鍵暗号方式であり、比較的小さな鍵サイズを必要とするため、計算 能力が制限されているデバイスでの使用に適している。
Provisioner はエフェメラルな公開鍵/秘密鍵ペアを生成し、選択されたベアラを使用して、その公開鍵を Bluetooth リンク経由で Provisionee に送信する。被提供者は、同じリンクを介して公開鍵を送信してもよいし、セキュリティを高めるために、QR コードや Near Field Communications（NFC）を使用するなど、帯域外（OOB）の方法を使用して公開鍵を提供してもよい。被提供者の公開鍵/秘密鍵ペアは、静的に定義されている場合もあれば、動的に生成される場合もある。
互いの公開鍵を手に入れたら、鍵合意プロトコルによって共有秘密が計算され、そこからセッション鍵が計算される。セッション鍵は、NetKeyの安全な転送に使用される。共有秘密鍵は、認証 ステップで使用される確認鍵とデバイスのデバイス鍵の計算にも使用される。
1.1.3.4認証
プロビジョニングは、多くのブルートゥース® メッシュデバイスがある場所で行われることがよくあります。プロビジョニングされるデバイスが意図されたものであることを確認し、中間者（MITM）攻撃から保護するために、プロビジョニング手順には認証 ステップが含まれます。
認証にはさまざまな形式があり、招待段階で受信した Provisioning Capabilities PDU を介して Provisioner に通知される、プロビジョニングされていないデバイスの能力に応じて選択される。
出力 OOB メソッドでは、プロビジョニングされていないデバイスが、そのデバイスがサ ポートするアクションを使用して数値またはテキスト値を出力します。たとえば、LED の点滅やビープ音の回数などです。出力された数値は Provisioner に入力され、確認プロシージャによって期待どおりの値が入力されたかどうかがチェックされます。
Input OOB 方式が使用される場合、Provisioner は乱数を生成し、適切な操作（たとえば、ボタンを何回か押す）を使用して未プロビジョニングデバイスに入力され、確認手順によって検証されます。
静的 OOB 方式では、固定値を使用する。固定値は、デバイスまたはそのパッケージに印刷されている 場合があり、Provisioner に入力され、確認手順で使用される。
どの方法が使用されたとしても、結果は、プロビジョニングされるデバイスの認証に成功するか失敗するかのいずれかであり、その結果をユーザーに通知する。
1.1.3.5 プロビジョニング・データの配布
認証成功すると、セッションキーが生成され、リンク経由で送信される Provisioning Data PDU の暗号化と認証に使用される。Provisioner は、プライマリ NetKey と、デバイスのプライマリエレメントの一意のユニキャストアドレス 含まれるデータを送信する。これで、デバイスはプロビジョニングされたことになる。
|
|
図2 - プロビジョニング・プロセスのステージ2～5 |
1.2 デバイスキーとコミッショニングプロセス
ブルートゥース® メッシュ・セキュリティ・システムにはいくつかのセキュリティ・キーがあり、それぞれが特定の役割を担っている。
ネットワークキーは、ネットワークレイヤーに関連するPDUのフィールドの 暗号化と認証 使用される。このように使用されることで証明される特定のネットワーク・キーの所有は、そのネットワーク・キーが属するサブネットのノードのメンバーシップ 意味する。
アプリケーション・キーは、Bluetooth Meshプロトコル・スタックの上位レイヤーに関連するPDUのフィールドの暗号化と認証 使用され、一般的に照明や空調などの特定のビル・システムの一部であるデバイスに発行されます。
ノードは複数のネットワーク鍵と複数のアプリケーション 鍵を持つことができる。
すべてのノードは1つのデバイス・キー（DevKey）を持っています。このキーは、通常はデバイスの設定に関連する、特定のモデルに属するメッセージを保護するために使用されます。ノードはプロビジョニング時にDevKeyを計算します。DevKeyがネットワーク上で転送されることはありません。
ブルートゥース® メッシュ・ネットワークが最初に構築される際、特にスマート・ビルディングの世界では、デバイスの設置、プロビジョニング、設定は通常、請負業者のチームによって行われ、最終的に完成したネットワークはビル所有者に引き渡されます。最適なセキュリティのためには、この時点でビル所有者がネットワーク内の各ノードのセキュリティキーを変更できるオプションがあることが望ましい。
Bluetooth Mesh 1.0ではKey Refresh手順が定義されており、ネットワーク・キーやアプリケーション キーをネットワーク全体で変更することができます。Bluetooth Mesh 1.0では、デバイス・キーを変更する手順は定義されていません。
1.3 ノードアドレス
ブルートゥース®メッシュにはアドレッシング・スキームがあります。
すべてのエレメントはユニークな16ビットのアドレス おり、これはすべてのメッセージのソースアドレス 使われ、時にはアドレス使われる。
グループ・アドレスとバーチャル・アドレスは、ノードの集まりを1つのメッセージでアドレス指定できるようにする2つのタイプのアドレス です。特定のグループアドレス バーチャルアドレス 送られたメッセージを受信して応答したいノードは、そのアドレス購読しなければなりません。
もともと、Bluetooth Meshのバージョン1.0では、Provisionerがまずエレメントをネットワークから削除してから再プロビジョニングしなければ、エレメントのユニキャストアドレス 変更できませんでした。
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 マルチホップ・デバイスのプロビジョニング
リモートプロビジョニングを使用すると、Provisionerと未プロビジョニングデバイスは、2つのデバイス間のネットワークを介した通信経路が形成されるのであれば、どこにいてもよい。このため、多くの実世界の状況において、より実用的なプロセスとなる。
2.1.2 所有者の変更
RPRは、ネットワーク内のデバイスの所有者が変わり、デバイス・キーの新しい値を確立できるようになった場合に役立つ手順を定義している。
2.1.3 動的デバイスの構成
自身の物理構成に対する変更を検出できる複合デバイスは、必要なメッシュ構成状態データ の変更を示すことができるようになった。Provisioner はこれを認識して 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をカプセル化し、クライアント サーバーの間でどちらかの方向に転送できるようにする。
- サーバーとなるノードのデバイス・キー（DevKey）で保護される。
- ノードプロビジョニングプロトコルインタフェース手順に関する。
概要では、リモート・プロビジョニングは、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のリストなど、既存のデータは影響を受けません。
この手順は、標準的なプロビジョニング・プロトコルと手順を使用して計算され る、デバイス鍵候補と呼ばれる新しい鍵候補で、2つのステージにわたって実行される。この鍵がデバイスから離れることはなく、楕円曲線暗号に基づくDiffie-Hellman鍵合意プロトコルが、Configuration Managerがそのコピーを安全に所有できるようにするために使用される。これにより、この手順に関連するセキュリティは、デバイスの最初のプロビジョニング時と同じレベルになります。この段階では、ノードのデバイス・キーは変更されていないが、新しいキーの候補値が ノードに知られている。ステージ 2 では、新しいデバイス鍵候補を使用して暗号化されたアクセス メッセージ受信すると、 デバイス鍵候補がノードの新しい DevKey となる。これは新しい鍵が使用中であることを示す。この時点で古い鍵は破棄され、新しいデバイス鍵候補がその代わりとなる。
2.2.3.2アドレス リフレッシュ
ノードアドレス リフレッシュ手順では、ノードのユニキャスト・アドレス デバイス・キーを、ノードをリセットして再プロビジョニングすることなく変更できます。ノードの NetKey や AppKey のリストなどの既存のデータは影響を受けません。各エレメントには、プライマリ・エレメントに割り当てられた新しいユニキャスト・アドレス 始まる連続した範囲を形成するアドレス 割り当てられます。
2.2.3.3 ノード構成のリフレッシュ
この手順により、ノードの構成（要素やモデルの数）を変更することができ、物理的な構成構造が動的な複雑なデバイスにプラグアンドプレイ機能を提供することができる。
ネットワーク内のDALIデバイスを想像してみてください。このデバイスは洗練された照明product 、その内部バスは最大128の異なるコンポーネントを収容することができます。例えば、様々な種類のセンサーがノードに差し込まれたり、抜かれたりします。この種のデバイスは、適切なファームウェアでプログラムされると、このような種類の変化を検出することができます。
このNPPI手順は、物理的な構成の変更を検出したノードが、構成データ 状態のページ128に詳細を書き込むことを要求する。PBクライアント開始されるこの手順は、最終的に、新しい構成状態データがページ128から、アクティブな構成状態データが格納されているページ0にコピーされ、必要な変更をもたらす。
このプロシージャが実行されると、新しいデバイス・キーもノードに割り当てられる。構成データ 状態はこの手続きによって更新されるが、他の状態は変更されない。
2.2.4 リモートプロビジョニングとセキュリティ
図9は、リモート・プロビジョニングのセキュリティ保護方法を示している。PB-Remoteクライアント サーバーが交換するメッセージは、PB-Remoteサーバーノードのデバイス鍵を使用して保護される。その後実行されるプロビジョニング手順は、1.1.3 節で説明される通常のプロビジョニング手順のステージ 2 ～ 5 を通過し、標準的なプロビジョニング・セキュリティを使用する。
図 9 - リモート・プロビジョニング・セキュリティ
デバイスがサポートする認証 方法のなかには、ユーザーがデバイスを見たり、聞いたり、触れたりできることに依存しているものがある。リモートプロビジョニングは、Provisioner からかなり離れた場所にあるデバイスのプロビジョニングを可能にするように設計されているため、これらのタイプの認証 方法は、状況によっては最適でなかったり、実用的でなかったりする場合があります。幸い、ブルートゥース® Mesh バージョン 1.1 には、証明書ベースのプロビジョニングと呼ばれる、デバイスの目視外のリモートプロビジョニングに最適な新しい認証 アプローチも追加された。この機能については、「証明書ベースのプロビジョニング技術概要」を参照してください。
2.2.5 バルク・プロビジョニング
ブルートゥース® Mesh 1.0では、プロビジョニング時に新しいデバイスの電波の届く範囲に直接いる必要があるため、Provisionerを移動することなく、大規模なデバイスのコレクション（おそらくネットワーク内のすべてのデバイス）のプロビジョニングには適していませんでした。
リモート・プロビジョニングは、証明書ベースのプロビジョニングと組み合わせると、コミッショナーによって開始される単一の手順で、新しいネットワーク内のすべてのデバイスをプログラム的にプロビジョニングするために使用できるプロビジョニング・ツールの可能性を提供する。
3.閉じる
ブルートゥース® メッシュのリモート・プロビジョニング機能は、ネットワークに新しいデバイスをプロビジョニングする作業をより簡単にします。新しいノード・プロビジョニング・プロトコルのインターフェイス手順は、実際のユースケースを反映し、新しいネットワークの確立や複雑なデバイスのメンテナンスに関わる通常のワークフローを確実にサポートします。
