arm社mBed OS、LoRaWANマルチキャストファームウェアアップデートが可能に！

2018-12-13 (Thu)

2018年12月12日、arm社mBedデベロッパーエバンジェリストのJan JongboomさんのTwitterでarm社mBed OSに組み込まれたLoRaWAN上でマルチキャスト・ファームウェアアップデート機能が正式にサポートされました。

The @ArmMbed LoRaWAN Multicast Firmware Update Client is now available! With delta updates, asymmetric crypto, on-spec with @LoRaAlliance specifications. And all open-source under the Apache 2.0 license. https://t.co/r3Xj613UcV
— Jan Jongboom (@janjongboom) 2018年12月12日

＊2018年12月15日、arm Jan JongboomさんのYoutbe。　Private KeyとLoRaWANに実装されたPublic Keyとの関係も実行画面を表示しながら、IPネットワークを利用しなくてもLoRaWANでマルチキャストが実現する方法をわかりやすく解説。

＊左からLoRa技術を発明したSemtech社Nicolas Sorninさん, arm社mBedデベロッパーエバンジェリストJan Jongboomさん, The Things Network Cofounder&Tech Lead Joha Stokkingさん

LoRaWANのマルチキャスト対応ですが、Jan Jongboomさん、Johan Stokkingsさん、そしてLoRa変調方式を発明したNicolas Sorninさんの３人で開発を始めたプロジェクトでしたが、今後、Non-IP大規模ネットワークを構築する上で、このマルチキャスト対応ファームウェアアップデート機能はMUST、LoRaWANの今後の発展にも欠かすことのできない機能であると思いますので、　2017年10月のブログを再投稿します。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
2週間前、TTN CTOのJohanさん来日の際、最終日夕食後に新宿ヒルトンホテルでオランダの親友と約束しているという。　親友を紹介したいので一緒にきてほしいと言われ、一緒にホテルに行き、バーラウンジでJazzを演奏を聞いていたARMエバンジェリスト、Janさんを紹介されました。

残念ながら、深夜まで一緒にカラオケを歌うことができませんでしたが、Janさんは、ARM本社採用エンジニアらしく、人懐こい顔で少しだけ会話をしました。　下記は、2016年6月アメリカ・フィラデルフィアで開催されたLoRa Alliance会議で発表したLoRaWANファームウェア・マルチキャストアップデートの動画です。左側が、ARMのJanさん、右側が、Johanさんの共同プロジェクトです。

Johanさんが投稿した記事を翻訳してみました。
↓↓↓↓↓↓↓↓↓
https://www.thethingsnetwork.org/article/firmware-updates-over-low-power-wide-area-networks/

以下は、訳文

ファームウェアのアップデートは、接続されたデバイスの大規模な展開に不可欠です。セキュリティパッチは、顧客およびビジネスデータを保護し、新しい機能、最適化、および特殊化により、デバイスの寿命が延びます。この記事では、最も困難なタイプのネットワーク、低消費電力ネットワーク、長距離ネットワークに関するファームウェアのアップデートについて説明します。

今後数年間で何十億ものIoTデバイスが市場に登場し、業界のリーダーたちは数十億ドルものエコシステムに注いでいます。 IoTデバイスは、バッテリ寿命が長く続く長距離および低消費電力の両方を必要とします。携帯電話やWi-Fiなどの従来の無線ネットワークテクノロジーでは、これらのニーズに対応できません。デバイスの要件を容易にするために、過去数年間、いわゆる低電力ワイドエリアネットワーク（LPWAN）という新しいネットワーク技術が登場しました。 LoRaWAN、Sigfox、NB-IoTなどのネットワークは、数キロメートルの範囲で非常に低いバッテリ消費量を持つ安価な無線チップを使用します。

これらのネットワークの欠点は、データレートが従来の無線ネットワークのデータレートよりもはるかに低いことです。 LPWANのデータレートは、1秒あたりのメガバイトではなく、毎秒のビット数で測定されます。さらに、これらのネットワークの多くは、デバイスがデューティサイクル制限に従うことを要求する無認可スペクトル（ISM帯域）で動作し、干渉の影響を受けてわずかな時間しか送信できません。

これらの特性により、大規模なファームウェアアップデートをサポートすることが困難になります。つまり、現場に配置されているほとんどのデバイスを更新することはできません。デバイスは手が届かない場所に配置されているか、技術者を派遣するには、コストが高すぎます。

IoTデバイス上のファームウェアを更新できないことは、実際の導入を行う際には問題です。まず最初は、2016年に何度も発生した100％セキュアなソフトウェアを書くことは不可能です.　　2つ目は、これらのデバイスは最長10年続くと思われるため、最新の標準プロトコルをアップデートすることがますます重要になります。最後に、機能を追加したり、製造や流通から所有権の移行や目的の変更に至るまで、デバイスをライフサイクル全体にわたって特殊化することができれば、さまざまなビジネスケースを確保できます。

これにより、LoRa Alliance参加者の中で積極的なメンバーであるJan Jongboom（ARM主任アプリケーションエンジニア）とJohan Stokking（CTO＆共同設立者、The Things Industries）は、これらのデバイスを適切に許可する提案 LPWANで更新することを考えました。この作業デモンストレーションは、フィラデルフィアのLoRa Alliance全会員会議とオープンハウスで、2017年6月12-14日に行われました。

この記事では、LoRaWANでの作業、および消費電力、リンク損失、データレートの制限に関する課題に焦点を当てます。これらの課題は他のLPWANにも当てはまります。

LPWANを介したファームウェアアップデートの重要な要件は次のとおりです。

1.電力消費とチャネル利用の観点から効率的に同時に複数のデバイスにデータを送信する機能（いわゆるマルチキャスト）
2.紛失したパケットからの回復
3.エンドツーエンドの標準に従って、ファームウェアの信頼性と完全性を確認する。

この記事では、これらの課題を1つずつ解説し、解決策を提示します。

＊マルチキャストサポートの追加
デバイスが常にネットワークとの接続を維持する携帯網またはWi-Fiとは異なり、LoRaWANを含むほとんどのLPWANはアップリンク指向です。換言すれば、データ（アップリンク）を送信することは、データを受信すること（ダウンリンク）よりも重要である。設定された時間にダウンリンクメッセージを送信することのみが可能であり、その間にウィンドウはRXウィンドウと呼ばれる。これらのRXウィンドウは、送信の直後にのみ開きます。

ファームウェアイメージを送信するには、これはひどいことです：多くのパケットのダウンリンク指向の送信が必要です。 2番目に高いLoRaWANデータレートで115バイトのペイロードサイズ（拡散係数9の最大値）を使用する場合は、891メッセージを交換して100 KBのファームウェアイメージを送信する必要があります。

多くの市場（ヨーロッパを含む）で1％のデューティサイクルがあるため、パケットロスがないと仮定して、1つのデバイスをアップデートするには9時間以上（メッセージあたり400ミリ秒の時間）が必要です。さらに、ゲートウェイは、デューティサイクルの制限を受ける数百または数千のデバイスをカバーすることがあり、そのため、デバイスの数を更新するには数週間かかる場合があります。

最後に、受信されたパケットごとに、必要な送信は多量のエネルギーを消費します（送信はLoRaおよびRX 9 mAhで40 mAhを消費します）。利用可能なスペクトルを多く使用します。
適切なファームウェアアップデートを有効にするには、デバイスとネットワークに次の2つの機能を追加する必要があります。

1.最初に送信する必要がないデバイスを使用せずにファームウェアイメージを送信し、デバイスのデューティサイクルと消費電力を最適化する方法。
2.マルチキャストサポート - 複数のデバイスを同時に更新し、ゲートウェイのデューティサイクルを最適化します。

最初のステップは、更新する必要があるすべてのデバイスを、同じ頻度、データレート、およびセキュリティセッションで正確に同じ時刻に受信することです。同じ鍵をデバイスにロードすると（LoRaWANはパケットにAES-128暗号化を使用します）、すべてのデバイスは、1つのデバイスであるかのように、同じパケットを受信および復号化できます。

デバイスがListenしていることが確実に確認されたら、最初にデバイスを送信する必要なく、ファームウェアイメージのブロードキャストを開始できます。これは、デバイスのスリープ動作に応じて、通常数時間または数日前にファームウェアのアップデートをスケジュールする必要があることを意味します。

デバイスは、一般に、活性化されている間にデバイスおよびネットワークに固有の安全なセッションで動作する。ほとんどのLPWANはアップリンク指向であるため、ネットワークは、関心のあるデバイスのマルチキャストグループを設定するための指示を送信する機会を得るために、デバイスが通常のメッセージを送信するのを待ちます。

第1の命令には、マルチキャストグループ内のすべてのデバイスに使用する一時的な共通デバイスアドレスとセキュリティセッションキーが含まれています。これには、グループが有効なパケットの最大数が含まれます。第2の命令は、デバイスに、各デバイスの相対的な秒数であるスリープから起きるときに、特定の周波数およびデータレートでListenを開始するように通知します。デバイスはネットワークへの指示を確認し、スケジュールされた時刻に更新を準備します。

アップデートウィンドウが開き、同時にすべてのデバイスがスリープ状態から復帰すると、ネットワークはできるだけ早くファームウェアの送信を開始できます。ネットワークは継続的にメッセージを送信できるため、891パケット（100 KByte）を6分以内に送信できます（1パケットあたり400 msの時間）。

ネットワークは依然としてパケットを送信するゲートウェイのデューティ・サイクル制限に従う必要があります。その後、これらのゲートウェイは、ファームウェアを送信してから比較的長い間静かである必要がありますが、メッセージは引き続き受信できます。ダウンリンクメッセージを送信する必要がある場合、別のゲートウェイがそれを処理できます。適切な設定では、デバイスの到達範囲内に複数のゲートウェイが常に存在し、チャネルの使用を均衡させます。

*マルチキャストセッションにおけるセキュリティ
複数のデバイスに、すべてのデバイスが同じセッションキーを共有する一時的なマルチキャストセッションに参加するように指示すると、デバイスの1つが危険にさらされ、潜在的なセキュリティリスクが発生します。マルチキャストセッションキーを持つことで、攻撃者はあたかもサーバから来たかのようにパケットを送信できます。これは、アクセス権を同時に制御するなどの追加のセキュリティ操作無しでマルチキャストを使用する場合、実際には深刻な問題が発生します。このアップデートメカニズムには、更新プロセスを保護するための3つの手段が含まれています。

まず最初に、ファイルが受信されると、デバイスは受信したデータのチェックサムを計算します。このチェックサムは、デバイスのプライベートセキュアセッションでサーバーに送信されます。サーバーは、このチェックサムと送信したデータのチェックサムを比較します。データが改ざんされていると、このチェックは失敗します。サーバは、チェックサムが正しいかどうかにかかわらず、プライベートセキュアセッションで、各デバイスに個別に応答します。

第二に、サーバーがチェックサムの正確性を示すためにサーバーの応答の一部として、サーバーはデータ整合性を保証するメッセージ完全互換性コード（MIC）を送信します。このMICは、デバイスのプライベートセキュアセッションキーを知らない人では偽造できません。デバイスとサーバだけが同じMICを計算できます。サーバーはデバイスのチェックサムをチェックし、デバイスはサーバーのMICをチェックし、デバイスのプライベートセキュアセッションで通信します。

第3に、攻撃者がランダムなパケットを注入すると、デバイスが元のイメージを再構築できないことがあります。次のセクションで説明するように、エラー訂正パケットの受信を継続しているために電源が切れるデバイスを回避するため、マルチキャストセッションの有効期間はメッセージの数に固定されています。この制限に達すると、デバイスはプライベートセキュアセッションに戻り、効率的な動作モードになり、すべてのデータを破棄します。

*不安定なネットワーク上で大きなバイナリパケットを送信
上記で提案されたスキーマでは、マルチキャスト送信が進行中のとき、装置とネットワークとの間に通信は存在しません。従って、ファームウェア更新のどの断片をどの装置が受信したかを判断することは不可能です。 LoRaWANネットワークでは、保証されたサービス品質はなく、デバイスが動いているときに確実にパケット損失が発生する可能性があります。高いパケット損失に対処するために、Nicolas Sornin（Semtech社チーフ技術者でありLoRa発明者）は、ストレージディスクに障害が発生した場合にRAID-6がエラー訂正を実行するのと同様に機能する断片化アルゴリズムを提案しました。

最初のステップでは、ネットワークはファームウェアをそのままパケットとして断片化して送信します。次に、ネットワークはエラー訂正パケットの送信を開始します。エラー訂正パケットは、受信したデバイスにXORされます。フラグメントはフレーム番号が増加しているため、デバイスは欠落しているフラグメントを認識し、訂正パケットを使用して欠落したフラグメントを再構築することができます。ネットワークは、すべてのデバイスがファームウェアアップデートのすべてのフラグメントを再構築したことを確認するまで、または極端なパケット損失の場合には、アップデートサーバがすべての修正パケットを送信するまで修正パケットを送信し続けます。エラー訂正アルゴリズムでは、欠落している3つのフラグメントを修正するために最大5つの修正パケットが必要です。

デバイスが完全なファームウェアを再構成した後、デバイスは、そのプライベートセキュアセッションおよび動作モードに戻ります。上記のようにデバイスのチェックサムとサーバーのメッセージ整合性コードを正常に確認した後、デバイスは、ファームウェアの更新を実行します。

*ファームウェアの暗号化検証
考案されたプロトコルは、ファームウェアの生データの完全性を処理します。それにはタイミングとメッセージレベルのセキュリティが含まれて、パケット損失の原因となります。しかし、適切なファームウェアの更新プロセスでは、ファームウェア更新のアルゴリズム自身を乗っ取ることができ、大きな攻撃要因の可能性があるため、ネットワーク層に新たな追加セキュリティが必要となります。

これらの攻撃から保護するために、リファレンス実装にはいくつかの追加プロパティが含まれています。

•デバイス上のファームウェアを更新する権限を持つ所有者のX.509証明書公開鍵。
•製造元のUUID（ユニバーサルユニークな識別子）
•デバイスタイプのUUID
•デバイスのUUID

実際のファームウェア更新には、更新に加えて、更新プログラムの暗号化ハッシュ、製造元、および更新プログラムが適用されるデバイスの種類からなるマニフェストが含まれています。すべてX.509証明書の製造元の秘密鍵で署名されています。デバイスが更新を受信するたびに、デバイスに製造元の公開鍵が含まれているため、信頼できる機関がそれを署名し、このデバイス用であるかどうかを確認できます。

デバイス上で実行されている更新クライアントと（実際のファームウェアが実行される前に実行される）ブートローダには、これらのチェックが含まれています。これらは、ARMがLoRaWAN上でファームウェアを安全に更新するために構築したリファレンス実装の一部であり、ARMは7月にApache 2.0ライセンスでリリースされる予定です。

*デモンストレーション
ファームウェアの更新プロセスを説明するため、Andrea Corrado（ARMの出身エンジニア）は、Multi-Tech xDot LoRa無線を搭載したカスタムボードを作成しました。このボードは、実際のアップデートクライアントを実行するターゲットMCU（NXP FRDM-K22F）に接続されます。この区別は、LoRaWANスタックと更新クライアントが別々のMCU上で実行されるため、迅速なプロトタイピングが可能になります。ただし、次のステップでは、近い将来、単一の自己更新可能なMCUでスタック全体を実行することになります。

さらに、Adafruit NeoPixel Shieldが添付されています。これには、8x5グリッドの超明るいマルチカラーLEDが含まれています。これらのLEDは、デモ中にステータスの更新を表示するために使用されます。

図：工場出荷の開発ボード

開発ボードの回路図と部品表は、mbed HDKの一部として利用可能になります。

ネットワーク側では、The Things Networkの分散型および分散型LoRaWANネットワークサーバーの上にアップデートサーバーが構築されました。アップデートサーバーは、アップデートのためのデバイス選択を調整し、ネットワークセキュリティとマルチキャストグループを設定し、フラグメントとエラー修正パケットをスケジュールし、ハッシュとファームウェアの整合性を検証します。現在、この更新サーバーはアプリケーション層にあります。

これにより、他のネットワーク技術への移植が容易になります。しかし、オープンスタンダードの提唱者として、プロトコルはLoRaWAN仕様に含めることが提案されます。これにより、LoRa Allianceのデバイスメーカやネットワーク間で相互運用可能なアップデートプロセスが幅広く採用されます。 The Things Industriesは、MITライセンスの下で更新サーバーをリリースします。

*まとめ
ファームウェアの更新機能は、接続性のためにLPWANを使用するデバイスが市場に出回った場合に不可欠な要件です。デバイスメーカは、製品の出荷時に、デバイスの寿命を通じてセキュリティアップデート、新機能、最適化、および特殊化を顧客に保証することができます。

LoRaWAN仕様内の大規模なペイロードのマルチキャストサポートと断片化の標準化は、ネットワークをあまり輻輳させることなく、信頼性の高い方法で多くのデバイスに大きなペイロードを送信する機能を追加します。さらに、リファレンスデザインには、この仕様の上にファームウェアの暗号化検証も含まれているため、ソリューションは安全であり、実際にはフィールドに展開できます。

市販のARM mbed OS 5を実行している複数のデバイスを使用してThe Things Networkで動作する完全なエンドツーエンドのライブソリューションとしてのこのデモンストレーションは、2017年6月12-14日開催せれたLoRa Alliance会議およびフィラデルフィアのオープンハウスで開催されました。

中国蘇州市で開催されたLoRa Allianceセミナーで、Janさんが発表した説明資料です。

Extending the life of your device (firmware updates over LoRa) - LoRa AMM from Jan Jongboom

↓↓↓↓↓↓↓↓↓↓↓↓↓↓

https://www.lora-alliance.org/amm9

↓↓↓↓↓↓↓↓↓↓↓↓↓↓

The Things NetworkとARMの共同プロジェクト - LoRaWANファームウェアアップデート機能

↓↓↓↓↓↓↓↓↓↓↓↓↓↓
LoRa Alliance Tokyoへ行ってきました！

↓↓↓↓↓↓↓↓↓↓↓↓↓↓

ＬoRaWANがOTAに対応、遠隔からファームウェアのアップデートが可能に

体系化されたＦＵＯＴＡ対応LoRaWANスタックは、大規模IoTシステムで必須機能です。

『今回LoRa Alliance Tokyoで発表された新仕様は具体的には、

　・時刻同期用の「LoRaWAN Application Layer Clock Synchronization Specification v1.0.0」、
　・マルチキャスト用の「LoRaWAN Remote Multicast Setup Specification v1.0.0」、
　・大容量ファイルのユニキャスト用の「LoRaWAN Fragmented Data Block Transport Specification v1.0.0」

の3つで構成され、いずれもFUOTAを実現するためのものだ。FUOTAの機能を利用するためには、新仕様に対応した新しいスタックが必要。既存のLoRaWANデバイスは、そのままではFUOTAを利用できない』

◆LoRa IoTスターターキットをThe Things Networkで試すパート1：LoRaWANとキットの紹介
↓↓↓↓↓↓↓↓↓↓↓
https://www.rs-online.com/designspark/getting-start-the-lora-iot-starter-kit-with-the-things-network-part1-jp

無免許長距離無線通信ネットワーク LPWANの代表例であるLoRaWANは，センサデバイスとセキュアに通信するため暗号化して通信する仕組みが導入されています。通信開始時は、「アクティベーション」により暗号鍵を交換しますが、この方式にはABPとOTAAの２種類があります。今後、LoRaWANの発展において理解が重要であるこの2種類の方式について解説します。
↓↓↓↓↓↓↓↓↓↓↓
https://www.rs-online.com/designspark/what-is-the-activation-method-on-lorawan-abp-and-otaa-jp

以上

■The Things Network - LoRaWANをみんなでシェアして使う　新刊本好評発売中！