ブルートゥース®メッシュ・デバイスのファームウェア・アップデート

リリース：	1.0.0
文書バージョン：	1.0
最終更新日：	2023年9月19日
著者：	マーティン・ウーリー、BluetoothSIG ハンヌ・マラット、シリコン研究所オムカー・クルカルニ、ノルディック・セミコンダクター

改訂履歴

Version	Date	Author	Changes
1.0.0	September 19, 2023	Martin Woolley, Bluetooth SIG Hannu Mallat, Silicon Laboratories Omkar Kulkarni, Nordic Semiconductor	Initial version

注

Bluetooth Mesh Profile Specificationは名称が変更され、Bluetooth Meshと呼ばれるようになりました。 プロトコル仕様と呼ばれるようになりました。本書および関連論文では、バージョン1.1仕様に言及する場合はこの名称を使用しますが、バージョン1.0仕様については引き続きBluetooth Mesh プロファイル仕様と呼びます。

1.背景

ブルートゥース® メッシュ 1.1 は、デバイス上で動作しているファームウェアをネットワーク全体でアップデートすることを可能にする、一連の新しい機能を導入した。この機能機能、利点、技術的なハイライトをレビューする前に、関連する背景を紹介する。

1.1 ファームウェアとBluetoothメッシュデバイス

デバイスのハードウェアを制御する低レベルのソフトウェアは、通常次のように呼ばれる。 ファームウェア.ブルートゥース・メッシュ・デバイスは、ブルートゥース・メッシュ・プロトコルとBluetooth LE host およびコントローラの基礎となるレイヤーを実装するファームウェアを実行します。メッシュ モデルデバイスが使用するメッシュ・モデルは、それ自体がファームウェアに実装されています。デバイスのファームウェアは、そのデバイスを実現する上で重要な役割を果たします。

1.2 ファームウェアを最新に保つ

ファームウェアは常に最新の状態に保つ必要があり、メーカーはしばしばファームウェア・アップデートをリリースする。新しいファームウェアは、問題を修正したり、新機能を追加したり、セキュリティを向上させたり、パフォーマンスを向上させたり、その他の利点を提供したりします。ソフトウェアがデバイスのファームウェアであれ、アプリケーションソフトウェアであれ、オペレーティングシステムのアップデートであれ、ソフトウェアを常に最新の状態に保つことは、一般的に良い習慣として受け入れられています。

ソフトウェアのアップデート方法は、ソフトウェアの種類やプラットフォームによって異なります。最近のスマートフォンやデスクトップOSでは、ユーザーの関与をほとんど必要としない自動ソフトウェアアップデートが主流となっている。.

ブルートゥース® メッシュ 1.0 は、新しいファームウェアがデバイスで利用可能であることを検出するための自動的または標準化されたメカニズムを提供していない。これらのタスクは、手動で実行する必要があり、ファームウェア・アップデートのインストールは、この目的のために提供されている独自のインターフェイスを使用して、デバイスに直接行わなければならない。複数のベンダーのデバイスで構成されるメッシュ・ネットワークでは、このプロセスは、複数の独自ツールを含み、非常に複雑になる可能性がある。

1.3 バイナリ画像

ファームウェアのアップデートは通常、イメージファイルとして知られる単一のバイナリファイルに収められます。 イメージ.イメージ・ファイルのフォーマットは様々で、ターゲット・プラットフォームとその製造元に依存します。ファームウェアの解凍、検証、インストールには、メーカー独自の手順が必要です。

1.4 ファームウェアの更新とセキュリティ

新しいファームウェアのインストールには、セキュリティ上のリスクが伴う。インストールされるソフトウェアが、謳い文句どおり製造元から提供されたものであることを、どうやって確認するのか？それが改ざんされておらず、おそらく悪意のあるコードが組み込まれていないことを、どうやって確認するのか？

このようなことは、ブルートゥース® 仕様の範囲外です。しかし、一般的には、ファームウェアイメージが改ざんされていないことを確認するために、オリジネーターによってデジタル署名されたファイルのみを使用することを推奨します。デジタル署名は、ファイルが検出されずに改ざんされるのを防ぎ、ファイルのオリジネーターを検証します。同様に、ファームウェア・アップデートがダウンロードされる可能性のあるサーバーを 信頼できるソース通常、デジタル証明書の使用によって達成される。

1.5 モデル

モデルは、ブルートゥース® メッシュ・デバイスの動作を構成するブロックです。モデルとは、特定の動作セットを実装し、定義されたメッセージと状態のセットを関連付けたソフトウェア・コンポーネントです。モデルには、メッセージの送受信のみを行うクライアント、メッセージの送受信を行い、モデルのメッセージによって動作する状態含むサーバー・モデルがあります。

2.機器ファームウェアのアップデートについて

2.1 能力とメリット

2.1.1 デバイス・ファームウェアのアップデート

ブルートゥース® メッシュの新しいデバイス・ファームウェア・アップデート（DFU）機能、ネットワーク内のノードがファームウェアを最新の状態に保つための標準的な方法を追加します。その機能には、新しいファームウェア・アップデートの有無の監視、バイナリ・イメージの取得、ネットワーク内での配布、選択したノードのアップデートが含まれます。

一般的なネットワークには、通常、同じメーカーの同じタイプの製品が多数含まれています。DFU機能 マルチキャストこれは、Bluetooth Mesh で使用されるブロードキャスト通信を活用したファームウェア配布機能で、最小限の無線通信回数で、単一のファームウェア・アップデート・イメージを複数のデバイスに一度に配布することができます。

DFUは、ネットワークのデバイスで実行されているファームウェアを最新の状態に保つために、ビルの保守チームが必要とする手作業を大幅に削減します。

2.1.2 プラグ＆プレイ

DFU機能、多くのサブシステムで構成され、それぞれが独自のファームウェアを持つデバイスのアップデートが可能になります。そのようなファームウェア・インスタンスはそれぞれ、デバイスのファームウェア情報リストにリストされています。

ファームウェア情報リストは動的です。つまり、プラグアンドプレイ・コンポーネントが追加または削除されると、サブシステムの変更がデバイスのファームウェア情報リストに反映されます。

新しいプラグアンドプレイ機能に関連して、Bluetooth Mesh Protocol Specification 1.1では、デバイスのライフサイクルとその構造と構成に新しい正式名称が導入されました。用語の概念用語の概念は、仕様の中で次のように説明されています：

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

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

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

A 期間が終了し、新しい タームが開始する。ノードアドレス更新プロシージャまたはノード構成更新プロシージャが実行されると、期間が終了し、新しい期間が開始する。

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

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

2.2.1 DFUの役割

DFUシステムはいくつかのノードの役割を定義している。その役割とは

Role	Description
Initiator	The Initiator identifies available firmware updates for a given list of nodes in the network. It executes procedures defined in the DFU specification under the control of an application. The Initiator typically runs on a device which supports both Bluetooth® Mesh and has internet connectivity, such as a smartphone or gateway device, and periodically checks manufacturers’ websites for new firmware releases. Having identified relevant updates, it acquires them and sends the new firmware images to a Distributor node.
Distributor	The Distributor receives new firmware images from an Initiator and is responsible for sending them to appropriate nodes in the network for installation. The Distributor is typically a physically separate device to the Initiator so that the Initiator (which will often be a smartphone application) does not need to be in range of the network during the entire process. The Distributor can be thought of as acting an intermediary for the Initiator.
Target	Target is the name given to a node which can receive a firmware image from a Distributor and install it.
Stand-alone Updater	A Stand-alone Updater fulfils the role of a combined Initiator and Distributor, acquiring firmware updates and sending them directly to Target nodes without the need for an intermediate Distributor.

2.2.2 モデル

DFU機能、いくつかの新しいメッシュモデルと、それらに関連する一連の手続きに基づいている。

輸送 トランスポートモデルは、ノード間でバイナリラージオブジェクト（BLOB）を転送するための一般化されたメカニズムを提供する。
ファームウェア ファームウェア配布モデルは、ファームウェア・アップデートをターゲット・ノードに配布する手順をサポートしています。

ファームウェア ファームウェア・アップデートモデルは、デバイスのファームウェアを更新する手順をサポートしています。

各モデルは、利用可能なファームウェア・アップデートが特定され、入手され、関連するノードに配布され、検証され、インストールされることを可能にする一連の手順に関与する。

2.2.3 役割とモデル

以下の表はDFUの仕様書から抜粋したもので、DFUの役割と新モデルの関係を示している。

役割	ファームウェア配布クライアント	ファームウェア配布サーバー	ファームウェアクライアントアップデート	ファームウェア・アップデート・サーバー	BLOB転送クライアント	BLOB転送サーバー
ターゲット	-	-	-	M	-	M
イニシエータ	M	-	M	-	M	-
ディストリビューター	-	M	M	-	M	M
スタンドアロン・アップデータ	-	-	M	-	M	-

M：この役割によるこのモデルのサポートは必須だ。

メッシュ・ノードは、それぞれの役割に関連するモデルをインスタンス化することで、複数の役割をサポートすることができる。

2.2.4 ファームウェア更新手順の概要

ファームウェア・アップデートの取得、配布、インストールを行う方法には、多くのバリエーションがある。たとえば

ファームウェアは、ディストリビューターがベンダーのウェブサイトから標準の ファームウェア・チェック・オーバー HTTPS 手順で、または実装固有の手順で、ベンダーのウェブサイトからファームウェアを入手することができます。
イニシエータ、ファームウェア・イメージを入手し、更新ノードに配布するためにそれをディストリビューターに送信してもよいし、ディストリビューターがファームウェア・イメージを自分で入手するための情報を送信してもよい。

イニシエータ、ディストリビュータ・ノード、および 1 つ以上のターゲット・ノードが、ファームウェア・アップデートを取得、配布、インストールするために、どのように協力し合うかの代表的な例を図 1 に示す。に示し、それに続く文章で説明する。

2.2.4.1 ファームウェアアップデートの検索と配布

図1 - ファームウェア・アップデートの取得と配布

図 1 は、ベンダーの Web サイトからファームウェア・アップデートを取得し、アップデート・ノード・セットに配布し、インストールする一連の手順を示している。様々な DFU の役割を果たすノード間の相互作用が示され、適切な場合には、関係する特定のモデルが示されている。

要約すると、次のようになる：

イニシエータ、上位レイヤーのアプリケーション指定されたノードのリスト上で現在実行されているファームウェアに関する情報を取得する。
イニシエータ、このファームウェアに関連するアップデートがあるかどうかをチェックする。利用可能なアップデートがあれば、それがダウンロードされる。利用可能なアップデートがない場合、プロセスはこの時点で終了する。
次に、イニシエータ、更新ノードのリストの詳細を ディストリビューション・レシーバ・リスト状態に追加します。簡単のため、リスト内の各ノードは、同じファームウェア・イメージを受け入れることができるべきであることに注意すること。
イニシエータ ファームウェアのアップロードと BLOB転送手順を使用してファームウェアイメージをディストリビュータに転送します。
その後、イニシエータディストリビューターに配給を開始するよう指示する。
ディストリビューターのファームウェア・アップデート・クライアント、各アップデート・ノードの対応するサーバー・モデルに、ファームウェア・アップデート手順が開始されることを通知し、返信としてステータス・メッセージを受け取ることを期待します。
7.ディストリビュータは、BLOB 転送手順を使用して、ファームウェアイメージを各アップデート n に転送する。

2.2.4.2 配信の進行状況を確認する

アップデート・ノードへのファームウェアの配布が行われている間、イニシエータディストリビューターに進捗状況についての情報を求めることができる。

図 2イニシエータ進捗状況の確認

2.2.4.3 ファームウェアの確認とインストール

完全なバイナリイメージを受信すると、更新ノードは、例えば BLOB 上のデジタル署名をチェックするなど、実装固有の検証チェックを実行する。ディストリビューターは、アップデーティング・ノードにおけるプロシーディングのステータスを監視し、適切な場合、アップデーティング・ノードに対してファームウェア・アップデートをインストールするよう指示する。

図 3- ファームウェア・イメージのアップデートと検証、そして指示があればそれをインストールするノード

2.2.5 ファイル形式

定義された ファームウェア取得手順は、Bluetooth Mesh Protocol Specification で定義されているアーカイブ・ファイル・フォーマットを使用すること。このフォーマットには、ファイルの内容を記述するマニフェスト・ファイル、バイナリのファームウェア・イメージ・ファイル自体、およびファームウェア・イメージに関する追加情報を含むオプションのメタデータ・ファイルが含まれる。マニフェスト・ファイルとメタデータ・ファイルは、定義された JSON フォーマットを使用します。

2.2.6 ファームウェアサブシステム

ノードは、そのファームウェアをいくつかの部分に分割することができる。それぞれの独立した部分は、ファームウェア・サブシステムと呼ばれる。例えば、ノードのメッシュ・ネットワーキング・スタックは、独立したファームウェア・サブシステムかもしれない。

2.2.7 URIの更新

ファームウェア・アップデート・サーバーのモデルには、ファームウェア情報状態呼ばれる状態含まれます。これは、Update URI と関連するファームウェア ID から構成される。ファームウェア ID は、ノード上のファームウェア・サブシステムを識別し、Update URI状態値は、このファームウェアのアップデートの場所を示す。メッシュ DFU 仕様は、この情報をどのように使用してダウンロード URI を構築するかを示している。 HTTP を介したファームウェア・チェックプロシージャで使用するためのダウンロード URI を構築するために、この情報がどのように使用されるかを示している：

https://mesh.example.com/check-for-updates/check?cfwid=02FF10000203

2.2.8 輸送コンセプト

BLOB 転送モデルは、あらゆるタイプのバイナリー・ラージ・オブジェクトの転送を可能にするように設計されている。しかし、ブルートゥース® メッシュ・プロトコル仕様のバージョン 1.1 では、BLOB 転送モデルの使用は、アップデート・ノードへのファームウェア・イメージの配布に限られている。BLOB 転送モデルの一般化された機能を理解することは、デバイスのファームウェア・アップデートの機能理解する上で重要である。

図4：BLOB転送モデル。画像をブロックに分割し、ブロックをチャンクに分割する様子を示す。

2.2.8.1 blob id

すべてのBLOBには、BLOB転送手続き中に使用する一意の8オクテットの識別子が割り当てられている。

2.2.8.2 ブロックとチャンク

BLOB は、BLOB 転送クライアントによって一連のブロックに分割されます。ブロックサイズはクライアントによって照会される宛先BLOB 転送サーバーの機能を参照して決定されます。

ブロックは チャンクブロックは同じ大きさのチャンクに分割される（最後のチャンクは別で、ブロックサイズがチャンクサイズの正確な倍数でない場合、他のチャンクより小さくなることがある）。

各BLOB転送サーバーは、扱える最大のチャンクサイズを含む多くのパラメーターを計算する。最大チャンクサイズの計算には、クライアントサーバーの最大送信単位（MTU）が関係する。転送が初期化されるとき、クライアントこの転送で使用されるチャンクサイズを計算する。

各チャンクには16ビットの チャンク番号が割り当てられる。

2.2.8.3 転送モード

つのBLOB転送モードが定義されている。

プッシュBLOB転送モード プッシュBLOB転送モードクライアント BLOB転送モードでは、クライアントフローを制御する。一度に一つのブロックが、一連のチャンクとして、ユニキャストアドレスマルチキャストアドレスどちらかに転送される。その後、クライアントサーバーに問い合わせて、どのチャンクを受信したかを判断し、欠落しているチャンクは再送される。

このモードでは プルBLOB転送モードでは、サーバーがフローを制御する。このモードは、主に低電力ノードで使用するために設計されており、一度に1つのサーバーにのみ、クライアント BLOBを転送するために使用されます。

2.2.8.4 転送ステータスの追跡

ブルートゥース® メッシュ・ネットワークの性質は、マルチパス、マルチホップのメッセージングと、信頼性を高めるための再送信システムにより、メッセージの配信順序がいかなる形でも保証されないことを意味します。そのため、BLOBが分割されたブロックのチャンクを伝達するBLOB転送メッセージも、特定の順序で到着することは保証できません。そのため、BLOB転送クライアントブロックをどのような順序で選択してもよく、ブロックを選択した後、そのチャンクをどのような順序で送信してもよい。

BLOB転送サーバーモデルに属するMissing Chunksと呼ばれる状態、アクティブブロック内の各チャンクのステータスを追跡できる手段を提供する。欠落チャンク状態ビットマスクが含まれ、以下のように使用される。状態値の各ビット位置は、そのチャンク番号に対応するチャンクのステータスを示す。つまり、例えばビット位置7は、現在のブロックのチャンク番号7のステータスを示す。値 1 はチャンクが受信されていないことを意味し、値 0 はチャンクが受信されたことを意味する。

BLOB転送クライアント、転送先のサーバーからMissing Chunks状態値を取得し、それを使って、受信されなかったチャンクのうち、まだ転送が必要なチャンクや再送が必要なチャンクを特定する。

2.2.9 セキュリティ

ソフトウェアを最新の状態に維持することは、あらゆる種類のコンピューティング・デバイスを安全に保つ上で、一般的に受け入れられているベスト・プラクティスである。しかし、ソフトウェアの入手やインストールには、それなりのセキュリティ・リスクが伴います。重要なのは、信頼できるソースからソフトウェアを入手していること、ダウンロードしたコードが何らかの形で改ざんされていないこと、ダウンロード中に改ざんできないことを確認することです。HTTPS を使用することで、パッシブ・スヌーパーが、あなたが現在ネットワークで実行しているファームウェアのバージョンや、どのバージョンにアップデートしようとしているのかを知ることを防ぐこともできる。攻撃者が、特定のファームウェア・バージョンにおける特定の脆弱性を知っている場合、これは貴重な情報となりうる。

DFU仕様では、この2つの問題にどうアドレスするかを実装者が決定する必要がある。

その ファームウェアの更新チェックプロシージャは、実装者に、指定された ファームウェア・チェック・オーバー HTTPS と HTTPS によるファームウェア取得プロシージャを使用するか、実装固有のプロシージャを使用するかを選択できます。

HTTPS でのファームウェアチェック ファームウェアチェックおよび/または HTTPS によるファームウェア取得手順では、安全な HTTPS プロトコルのみが使用できます。HTTPS プロトコルは、飛行中のデータが暗号化されることを保証し、HTTPクライアントサーバーの主張する身元を認証できるように、サーバーがデジタル証明書を持つことを要求します。データは暗号化され、2つのエンドポイント間で送信されるデータを改ざんしようとする試みはすべて検出されます。

実装者は、ファームウェア・アップデートのチェックと取得に、可能な限り最も安全なオプションを使用することを推奨する。

3.閉じる

ブルートゥース® メッシュ・デバイスのファームウェア・アップデートは、ベスト・プラクティスに従い、ネットワークのノードとして機能するデバイスのファームウェアを最新に保つことを容易にします。これは、ベンダーからの新しいリリースの可用性を自動的に監視し、シンプルで可能な限り控えめなユーザーエクスペリエンスをサポートするように設計されています。