Bluetooth Mesh リモートプロビジョニング

技術概要

リリース：	1.0.0
文書バージョン：	1.0
最終更新日：	2023年9月19日
著者：	マーティン・ウーリーBluetooth SIG オムカル・クルカルニ、ノルディック・セミコンダクターピョートル・ウィニアルチク、シルベア社

改訂履歴

Version	Date	Author	Changes
1.0.0	September 19, 2023	Martin Woolley, Bluetooth SIG Omkar Kulkarni, Nordic Semiconductor Piotr Winiarczyk, Silvair	Initial version

注

Bluetooth Mesh プロファイル仕様は名称が変更され、現在は次のように呼ばれている。Bluetooth Mesh プロトコル仕様と呼ばれるようになった。本書と関連論文でバージョン1.1仕様を参照する場合はこの名称を使用するが，バージョン1.0仕様を参照する場合は引き続きBluetooth Mesh プロファイル仕様書仕様と呼ぶことにする。

1.背景

リモート・プロビジョニング機能は、Bluetooth^® Mesh プロトコル仕様のバージョン1.1で導入された。その機能と利点を十分に理解するには、Bluetooth Mesh バージョン1.0のある側面を理解する必要がある。このセクションでは、この後のリモートプロビジョニングのレビューに役立つ文脈と背景を提供する。

1.1 プロビジョニング

デバイスは、プロビジョニングという行為によって、Bluetooth Mesh ネットワークのメンバーになります。プロビジョニングは、コミッショナーが Provisioner と呼ばれるデバイスまたはアプリケーションを使用して実行する手順です。デバイスをプロビジョニングすると、そのデバイスは、ネットワークのプライマリネットワークキー（NetKey）や、デバイスの要素に割り当てられた連続するユニキャストアドレスの一意の範囲など、特定の重要なデータ項目を所有することになります。プロビジョニング中のデバイスはProvisionee と呼ばれる。

本来、Bluetooth Mesh プロファイル仕様のバージョン 1.0 で定義されているように、Provisioner は Provisionee の直接の無線範囲内にいなければならない。

1.1.1 プロビジョニング・プロトコル

プロビジョニングの目的のみに使用されるプロトコルは、プロビジョニングプロトコルと呼ばれる。Bluetooth^® Mesh プロファイル仕様のバージョン1.0では、プロトコルは10種類のPDUを含んでいた。

1.1.2 ベアラのプロビジョニング

Bluetooth^® Mesh バージョン 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 がサポートされている場合、mesh プロビジョニング・サービスのUUID を含む接続可能な広告パケットがブロードキャストされる。両方のベアラがサポートされている場合、これら 2 種類の広告形態はインターリーブされる。

いずれの場合も、ビーコン・データにはプロビジョニングされていないデバイスのデバイスUUIDが含まれる。デバイスUUIDは、物理的またはソフトウェア製品の寿命期間中変わることのないデバイスの一意な識別子であり、通常は工場で割り当てられる。

1.1.3.2 招待

Provisioner は、GATT（mesh ）プロビジョニング・サービスに対応していることを示す未プロビジョニング・デバイス・ビーコンおよび／または接続可能な広告をスキャンし、選択された未プロビジョニング・デバイスとの 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 認証

プロビジョニングは、多くのBluetooth^® Mesh デバイスがある場所で行われることがよくあります。プロビジョニングされるデバイスが意図されたものであることを確認し、中間者（MITM）攻撃から保護するために、プロビジョニング手順には認証ステップが含まれます。

認証にはさまざまな形式があり、プロビジョニングされていないデバイスの能力に応じて選択される。この能力は、招待段階で受信したプロビジョニング能力PDUを介してプロビジョナに通知される。

出力 OOB メソッドでは、プロビジョニングされていないデバイスが、そのデバイスがサポートするアクションを使用して数値またはテキスト値を出力します。たとえば、LED の点滅やビープ音の回数などです。出力された数値は Provisioner に入力され、確認プロシージャによって期待どおりの値が入力されたかどうかがチェックされます。

Input OOB 方式が使用される場合、Provisioner は乱数を生成し、この乱数は適切な操作（たとえば、ボタンを何回か押す）を使用して未プロビジョニングデバイスに入力され、確認手順によって検証される。

静的 OOB 方式では、固定値を使用する。固定値は、デバイスまたはそのパッケージに印刷されている場合があり、Provisioner に入力され、確認手順で使用される。

どの方法が使用されるにせよ、結果は、プロビジョニングされるデバイスの認証に成功するか失敗するかのいずれかであり、その結果をユーザーに通知する。

1.1.3.5 プロビジョニング・データの配布

認証に成功すると、セッションキーが生成され、リンク経由で送信される Provisioning Data PDU の暗号化と認証に使用される。Provisioner は、プライマリ NetKey とデバイスのプライマリエレメントの一意のユニキャストアドレスを含むデータを送信する。これで、デバイスはプロビジョニングされたことになる。

図1 - プロビジョニングのステージ1 - ビーコン化

図2 - プロビジョニング・プロセスのステージ2～5

1.2 デバイスキーとコミッショニングプロセス

Bluetooth^® Mesh セキュリティ・システムにはいくつかのセキュリティ・キーがあり、それぞれが特定の役割を担っている。

ネットワークキーは、ネットワークレイヤーに関連するPDUのフィールドの暗号化と認証に使用される。このように使用されることで証明される特定のネットワークキーの所有は、そのネットワークキーが属するサブネットのノード（メンバーシップ）を意味する。

アプリケーション・キーは、Bluetooth Mesh プロトコル・スタックの上位レイヤーに関連するPDUのフィールドの暗号化と認証に使用され、一般に、照明や空調などの特定のビル・システムの一部であるデバイスに発行される。

ノードは複数のネットワーク鍵と複数のアプリケーション鍵を持つことができる。

すべてのノードは1つのデバイス・キー（DevKey）を持っています。このキーは、通常はデバイスの設定に関連する、特定のモデルに属するメッセージを保護するために使用されます。ノードはプロビジョニング時にDevKeyを計算します。DevKeyがネットワーク上で転送されることはありません。

Bluetooth^® Mesh ネットワークが最初に構築されるとき、特にスマート・ビルディングの世界では、通常、デバイスの設置、プロビジョニング、設定が業者のチームによって行われ、最終的に完成したネットワークがビル所有者に引き渡される。最適なセキュリティのためには、この時点で、ビル所有者がネットワーク内の各ノードのセキュリティ・キーを変更できるオプションを持っていることが望ましい。

Bluetooth Mesh 1.0ではKey Refresh手順が定義されており、ネットワーク・キーとアプリケーション・キーをネットワーク全体で変更できるようになっている。Bluetooth Mesh 1.0には、デバイス・キーを変更する手順は定義されていない。

1.3 ノードアドレス

Bluetooth^® Mesh にはアドレス指定スキームが含まれている。

すべてのエレメントは一意の16ビットのユニキャストアドレスを持ち、このアドレスはすべてのメッセージの送信元アドレスとして使われ、時には宛先アドレスとしても使われる。

グループアドレスとバーチャルアドレスは、ノードの集まりを1つのメッセージでアドレス指定できるようにする2つのタイプのアドレスです。特定のグループアドレスやバーチャルアドレスに送られたメッセージを受信し、応答したいノードは、そのアドレスを購読する必要があります。

元々、Bluetooth Mesh のバージョン1.0では、Provisionerがまずそのエレメントをネットワークから削除してから再プロビジョニングしなければ、エレメントのユニキャストアドレスを変更することはできなかった。

1.4 ノードの構成

ノードは論理的な構造を持つ。ノードは1つ以上のエレメントから構成される。エレメントはデバイスの個別にアドレス指定可能な部分であり、独自のユニキャスト・アドレスを持つ。ノード内のエレメント・アドレスは、プライマリ・エレメントが最下位アドレスとなるように、連続した範囲に割り当てる必要があります。

エレメントには1つ以上のモデルが含まれる。モデルは標準化されたソフトウェア・コンポーネントであり、デバイスのスイッチのオン・オフや明るさの変更などの機能をエレメントに提供する。モデルには、関連するステートと メッセージがあります。ほとんどの場合、ノードとエレメントとモデルの関係は、1つのノードが1:nのエレメントを含み、各エレメントが1:mのモデルを含む階層構造になっています。しかし、モデルの種類によっては、複数の要素が所有することもあるため、厳密な階層構造とはなりません。

ノードが持つ要素の具体的な数と、各要素が含む特定のモデルは、ノードの構成の一部です。ノードのコンポジションは、コンポジション・データ状態の情報によって表されます。このステートは、そのコンテンツをインデックスが付けられたいくつかのページに分割します。ページ 0 は重要で、そのノードの現在アクティブなコンポジション・データが含まれます。

Bluetooth^® Mesh バージョン1.0では、ノード・リセットを実行して再プロビジョニングしない限り、ノードの構成を変更することはできなかった。

1.5 複雑なデバイス

デバイスの中には複雑なものもあり、個々のコンポーネントが多数あり、それぞれがデバイス全体に特化した機能を付加しています。例えば、DALI（デジタル・アドレサブル・ライティング・インターフェイス）デバイスは、通信バスを中心に構築されており、センサーなどの個々のコンポーネントは、このバスに抜き差しすることができる。これらのデバイスは複雑な論理構造を持つ洗練されたものであるだけでなく、コンポーネントの追加や削除が容易であることから、その構成構造は動的である。

2.リモートプロビジョニングについて

リモート・プロビジョニング（RPR）は、Bluetooth^® Mesh プロトコル仕様のバージョン1.1で導入され、プロビジョナーの直接の無線範囲内にないノードのプロビジョニングと再プロビジョニングを、mesh ネットワーク上で可能にする。

2.1 能力とメリット

RPRは、3つのトピックに分類される機能と利点を提供する：

2.1.1 マルチホップ・デバイスのプロビジョニング

リモートプロビジョニングを使用すると、Provisionerと未プロビジョニングデバイスは、2つのデバイス間のネットワークを介した通信経路が形成可能であれば、場所を問わない。このため、多くの実世界の状況において、より実用的なプロセスとなる。

2.1.2 所有者の変更

RPRは、ネットワーク内のデバイスの所有者が変わり、デバイス・キーの新しい値を確立できるようになった場合に役立つ手順を定義している。

2.1.3 動的デバイスの構成

自身の物理的な構成の変更を検出できる複合デバイスは、必要なmesh 構成状態データの変更を示すことができるようになった。Provisioner はこれを認識して RPR 手順を開始し、アクティブなコンポジションデータの状態を更新して新しいコンポジションを反映させることができる。これまで必要であった、デバイスのリセット、再プロビジョニング、再設定は必要なくなりました。

新しいプラグアンドプレイ機能に関連して、mesh プロトコル仕様 1.1 では、デバイスのライフサイクルとその構造および構成に新しい正式名称が導入されている。Termの概念は、この仕様で以下のように説明されている：

A 期間とは、ノードの構造（すなわち、機能、エレメント、モデル）およびノードのエレメントのユニキャストアドレスが変更されない、ノードのライフタイム内の期間である。

新しいタームの開始は、補助センサの取り付けなど、物理デバイスのハードウェア構成の変更をサポートするため、または照明器具内ネットワークへの新しいギアの取り付けなど、ノード上のサブシステム構成の変更をサポートするために必要な場合がある。この変更は、ノードがコンポジション・データ・ページ128（セクション4.2.2.3参照）に入力することで示され、新しい期間が開始したときに有効になります。

最初の期間ネットワーク上のノードの初期期間は、そのノードがネットワーク上にプロビジョニングされた時点から始まります。

A 期間が終了し、新しい タームが開始する。は、ノードアドレス更新手順またはノード構成更新手順が実行されたときに開始する（セクション 3.11.8 参照）。

前期項ネットワーク上のノードの最後の項は、そのノードがネットワークから取り除かれた時点で終了する。

2.2 テクニカル・ハイライト

2.2.1 アーキテクチャ

リモート・プロビジョニングには、リモート・プロビジョニング・クライアント・モデルと リモート・プロビジョニング・サーバー・モデルという2つの新しいモデルが含まれる。リモートプロビジョニングクライアントモデルは、プロビジョナーデバイスがリモートの未プロビジョニングデバイスと通信し、プロビジョニングプロセスを制御することを可能にする。このデバイスは PB-Remote Client と呼ばれる。クライアントモデルは、モデルメッセージを使用してプロビジョニングプロトコル PDU を送受信する。メッセージは、管理されたフラッディング、有向転送、または 2 つの方法の組み合わせを使用して、通常の方法でネットワークを介して中継されます。リモートプロビジョニングサーバーモデルは、PB-Remote Client がその直接の無線範囲内にあるプロビジョニングされていないデバイスをスキャンし、プロビジョニングすることを可能にします。このモデルを実装したデバイスはPB-リモートサーバーと呼ばれます。サーバーモデルは、デバイスキーの変更やプラグアンドプレイデバイスの設定に必要な手順の実行もサポートします。

リモート・プロビジョニングは、PB-Remote プロビジョニング・ベアラも定義します。PB-Remote ベアラは、PB-ADV または PB-GATT を使用して、PB-Remote サーバー・デバイス上に実装されている場合、プロビジョニングされていないデバイスと通信します。PB-Remote サーバー・デバイス上に実装されている場合、このベアラによって、プロビジョナーはプロビジョニング・プロセスに参加しているリモート・デバイスと通信できます。

ノード・プロビジョニング・プロトコル・インターフェイスと呼ばれるインターフェイスが定義され、デバイス・キーの 変更やプラグアンドプレイ・デバイスの設定など、多くの重要な新手続きが可能になる。

リモート・プロビジョニング・モデルは、以下のメッセージを定義している：

プロビジョニングが可能で、PB-Remote Serverから直接電波の届く範囲にあるデバイスを、ネットワーク上のどこからでも検出できるようにします。
PB-Remoteサーバーと、選択されたプロビジョニングされていないノードとの間にリンクを確立できるようにする。
プロビジョニング・プロトコルのPDUをカプセル化し、クライアントとサーバーの間でどちらの方向にも転送できるようにする。
サーバーとなるノードのデバイス・キー（DevKey）で保護される。
ノードプロビジョニングプロトコルインタフェース手順に関する。

概要では、リモート・プロビジョニングは、PB-Remote Client の要求により、PB-Remote Server が選択されたプロビジョニングされていないデバイスへのリンクを確立することで機能する。その後、リモート・プロビジョニング・メッセージ内にカプセル化されたプロビジョニング・プロトコルPDUを受信し、それらのPDUを抽出してリンク上に送信し、PB-リモート・クライアントに送り返す他のリモート・プロビジョニング・メッセージ内にカプセル化されたプロビジョニング・プロトコルPDUを応答として受信します。図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-Remote Serverノードはリモートプロビジョニングスキャンステータスメッセージで応答します。

リモートプロビジョニングスキャンレポートメッセージは、PB-Remoteサーバーからスキャンを開始したPB-Remoteクライアントに送信されます。これらのメッセージには、サーバーがプロビジョニング可能な、検出されたプロビジョニングされていない各デバイスの詳細が含まれ、識別デバイスUUID、デバイスの帯域外（OOB）認証機能に関する情報、PB-Remoteサーバーが測定した信号強度（RSSI）、およびプロビジョニングされるデバイスからURIハッシュ値（利用可能な場合）が含まれます。シングル・デバイス・スキャンでは、指定されたデバイスUUIDのスキャン・レポート・メッセージのみが表示されます（デバイスが検出された場合）。

2.2.2.1.2 リモートプロビジョニング拡張スキャン手順

このリモート・スキャンのバリエーションにより、PB-リモート・クライアントは、（PB-ADV の場合）プロビジョニングされていないデバイス・ビーコン内や（PB-GATT の場合）接続可能な広告パケットのサービス・データ AD タイプ内では見つけられない、単一のデバイスに関する特定の追加情報を要求することができます。興味のある追加情報は、Bluetooth^®LE スキャン・レスポンス・パケットや、同一デバイスからの代替コンテンツを含む追加広告パケットで利用可能かもしれない。

拡張スキャンでは、単一のプロビジョニングされていないデバイス、またはPB-Remote Serverノード自体から情報を取得することができます。これらのシナリオのうち最初のシナリオでは、リモートプロビジョニング拡張スキャン手順は単一のデバイスに対してのみ実行されますが、PB-Remote Serverの実装がそれをサポートしている場合は、各々が異なるデバイスUUIDをターゲットとする手順の複数のインスタンスを同時に実行することができます。

PB-Remote Clientが送信するRemote Provisioning Extended Scan Startメッセージは、指定されたユニキャストアドレスを持つPB-Remote Serverノードによるリモート拡張スキャンを開始する。このメッセージには、値が要求される AD タイプのリストを含めることができます（Bluetooth Mesh プロトコル仕様に記載されている制限事項があります）。メッセージに Device UUID が含まれていれば、指定されたプロビジョニングされていないデバイスのスキャンが実行され、そうでなければ PB-Remote Server ノード自身から情報が取得される。

リモートプロビジョニング拡張スキャン開始が未承認のメッセージです。

リモートプロビジョニング拡張スキャンレポートメッセージは、拡張スキャンを開始したPB-リモートクライアントにサーバーから返送され、PB-リモートサーバーによって取得された要求されたタイプの情報が含まれます。

2.2.2.2 リンクを開く

図 5 - プロビジョニングされていないデバイスへのリモート・リンクを開く

PB-Remoteクライアントは、Device UUIDパラメータを指定してRemote Provisioning Link Openメッセージを送信し、PB-Remote Serverノードに指定されたデバイスとのプロビジョニングリンクの確立を要求することができます。これは確認メッセージであり、その結果、サーバーはリモート・プロビジョニング・リンク・ステータス・メッセージをクライアントに送り返します。図 5 を参照してください。

リモートプロビジョニングリンクオープンメッセージは、新しいノードプロビジョニングプロトコルインタフェース（2.2.3参照）を介して利用可能な他の手順のために、PB-Remoteサーバーを準備するために使用することができることに注意してください。

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 Client ノードに送り返されます。図 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 ノードアドレスのリフレッシュ

ノード・アドレス・リフレッシュ手順では、ノードをリセットして再プロビジョニングすることなく、ノードのユニキャスト・アドレスとデバイス・キーを変更できます。ノードのネットキーや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 - リモート・プロビジョニング・セキュリティ

デバイスがサポートする認証方法の中には、ユーザーがデバイスを見たり、聞いたり、触れたりできることに依存するものがある。リモートプロビジョニングは、Provisioner からかなり離れた場所にあるデバイスのプロビジョニングを可能にするように設計されているため、これらのタイプの認証方法は最適ではないか、状況によっては実用的でない場合があります。幸いなことに、Bluetooth^® Mesh バージョン 1.1 には、証明書ベースのプロビジョニングと呼ばれる、目視外のリモートデバイスのプロビジョニングに最適な新しい認証方法も追加されました。この機能については、「証明書ベースのプロビジョニング技術概要」で説明する。

2.2.5 バルク・プロビジョニング

Bluetooth^® Mesh 1.0 は、プロビジョニング時に新しいデバイスの電波の届く範囲に直接いる必要があるため、Provisioner を再配置せずに、大規模なデバイスのコレクション（おそらくネットワーク内のすべてのデバイス）をプロビジョニングするのに適していませんでした。

リモート・プロビジョニングは、証明書ベースのプロビジョニングと組み合わせると、コミッショナーによって開始される単一の手順で、新しいネットワーク内のすべてのデバイスをプログラム的にプロビジョニングするために使用できるプロビジョニング・ツールの可能性を提供する。

3.閉じる

Bluetooth^® Mesh リモート・プロビジョニング機能は、ネットワーク内の新しいデバイスのプロビジョニングをより簡単にします。新しいノード・プロビジョニング・プロトコルのインターフェイス手順は、実際のユースケースを反映しており、新しいネットワークの確立や複雑なデバイスの保守に関わる通常のワークフローが十分にサポートされていることを保証します。

Bluetooth Mesh リモートプロビジョニング