LoRaWANの2つのアクティベーション方式とは？ABPとOTAAについて解説します

LPWAの代表例であるLoRaWANでは，デバイスとセキュアに通信するため暗号化して通信する仕組みが導入されている。通信開始時には「アクティベーション」により暗号鍵を交換するが、この方式にはABPとOTAAの２種類がある。本記事では今後LoRaWANの発展において理解が重要であるこの2種類の方式について解説しよう。

LoRaWANは低消費電力で大規模ネットワークを構築する技術であるLPWA（Low Power Wide Area）の代表的な技術の一つである。

実際にスターターキットを用いた利用例については以下の記事を参考にしてほしい。

LoRa IoTスターターキットをThe Things Networkで試す ：LoRaWANとキットの紹介

もしLoRaWANを利用したシステムの開発を経験した方なら、「ABPとOTAA」という言葉は耳にしたことがあるのではないだろうか。

デバイスと通信を行う際、LoRaWANではLoRa無線という無線技術を利用してゲートウェイと通信を行う。しかし、そのままの通信では暗号化が行われておらず簡単に盗聴が可能だ。

そのためLoRaWANでは暗号化について定められており、この暗号化通信の開始時にアクティベーションを行う必要がある。アクティベーションとは、通信を行うデバイスを正規のものとして認識するために必要な手順のことだ。

LoRaWAN™ Specification v1.1(LoRaWANの最新の仕様)

このアクティベーション方式にはABP（Activation by Personalization）とOTAA（Over-the-Air Activation）の2種類がある。本記事では無料で利用可能であり、LoRaWANのデファクトスタンダードとも言えるThe Things Networkの実例を基にこの2つについて解説しよう。

なお、The Things Networkのアクティベーションについての仕様はこちらに公開されている。

The Things NetworkにおけるLoRaWAN Security

現在v1.0に従っているが、最新版のプロトコルスタックにてLoRaWAN Specification v1.1に準拠する予定だ。

それでは2つのアクティベーション方式について見ていこう。

ABP(Activation by Personalization)について

まずABPの概要図は以下のイメージの通りだ。

デバイスがセキュアに通信するには、デバイス毎に異なる「セッションキー」と「デバイスアドレス」が必要となる。これによって送信するデータ（正確にはペイロード）がAESという暗号化方式で暗号化され、LoRaWANサーバーと通信を行っている。また、データの送信ごとにカウンタの値が1ずつ増える。これにより、同じメッセージをなりすましてもサーバー側で無視される仕様だ。

ABPでは、事前にデバイスのプログラミングを行う人（ユーザーやデベロッパなど）がLoRaWANサーバーで事前に発行した各種キーとデバイスのアドレスを入手後、デバイスへと書き込むことで、最初の通信時からデータを暗号化して通信することができる。

それでは実際の例を参考にABPについて見ていこう。

ABPを利用した際、The Things Networkと通信するデバイスのシリアルコンソールのスクリーンショットは次の様になる。

このようにデバイスの電源が投入されるとすぐにデータの送信を行っている。

The Things NetworkのLoRaWANのゲートウェイでは、以下のイメージのようにカウンタとペイロード、デバイスアドレスを確認できる。

正しい認証情報をデバイスに書き込めている場合には、次のイメージのようにきちんとデータが届いていることがわかる。センサーのデータが復号されていることも確認できるだろう。

しかし、デバイス毎にアドレスとセッションキーは異なる。そのため、全てのデバイスを手動でプログラミングする必要があるのだ。つまり、LPWAのような大規模ネットワークの構築には向かないということになる。さらに常に同じキーを利用し続けるため、解析されてしまう危険もある。そのため、現在は次に紹介するOTAAというアクティベーション方式が推奨されている。

OTAA(Over-the-Air Activation)について

次にOTAAの概要図を次のイメージに示す。

OTAAでは、デバイスごとに異なる「セッションキー」と「デバイスアドレス」を必要とせず、最初にサーバーと通信に必要な情報の交換を行い、自動的にこれらの値を取得する仕組みだ。

まずは通信開始時に「参加要求（Join Request）」をLoRaWANサーバーへと送信する。これには各種EUI（デバイス毎に異なるID）などが含まれている。参加要求を受け取ったサーバーによって正しく承認された場合は、「要求承認（Join Accept）」を返す。この応答時にデバイスアドレスと各セッションキーを返す仕組みだ。以降の通信はABPと同じである。しかし、一度電源を落とすなどした場合、再度デバイスのアクティベーションを行うため、その都度新しいアドレスとセッションキーが割り当てられる。

この仕組みによって、鍵の解析などが行われても、電源を再度投入した際には異なる鍵を利用することになるため一般的にセキュアであり、さらにカウンタと併用することでよりセキュアとなっている。こうした理由から現在利用が推奨されている。

また各EUIやアプリケーションキーは、デバイス（のボード）出荷時に書き込まれることで、LoRaWANデバイスにユーザーが直接書き込むことなく、必要な処理のプログラミングのみでアクティベーションが可能となる。これにより、一斉にデバイスをばらまき、自動でアクティベーション が行われた後にデータの収集が可能になるなど、実際のサービス提供時には管理が楽になるというメリットもある。

それでは実際の例を基に、OTAAについて見ていこう。

The Things Networkと通信するデバイスのシリアルコンソールのスクリーンショットは次の様になる。

通信開始時にネットワーク参加要求を行い、正しくアクティベーションが行われるとデータの送信が開始される。

また参加要求が失敗すると、次のイメージのようにデータの送信が開始しない。

参加要求が正しく承認されない理由にはいくつか考えられる。例として、EUIがLoRaWANサーバーに登録されていない場合や、送信時の周波数をゲートウェイが受信出来ない場合、要求承認に対する応答メッセージ送信時の周波数が異なる場合などが考えられるだろう。

The Things NetworkのLoRaWANのゲートウェイでは、以下のイメージのようにメッセージを確認できる。最初の2メッセージは参加要求とそれに対する承認を意味しており、正しくアクティベーションされるとデータの送信が開始される。

正しくデバイスが承認された場合には、次のイメージのようにまず初めにアクティベーションが成功し、以降センサーのデータが届いていることがわかる。

まとめ

今回、2種類のアクティベーション方式であるABPとOTAAを中心にLoRaWANのセキュリティについて簡単に解説した。

ABPとOTAAについての違いをまとめると大体以下の通りだ。

• デバイスに手動で鍵を書き込む: ABP / 書き込まない: OTAA
• 通信開始時シンプル: ABP / 承認後通信開始: OTAA
• プロトタイプ向け: ABP / 大規模サービス向け: OTAA
• セキュリティの面ではABP < OTAA

基本的に開発の環境に応じて適切なアクティベーション方式を利用すれば良いが、もし可能ならOTAA方式を利用したほうが良いだろう。また同じLoRaWANサーバーでアクティベーションするデバイスの場合でも、ABPとOTAAが用途によって共存する場合もあるはずだ。

セキュリティ向上の仕組みとして、周波数ホッピング（frequency hopping：FHSS）という仕組みも導入されている。周波数をある程度の範囲内でランダムに利用することで、電波の盗聴や、なりすましといった攻撃からある程度守ることができるためだ。

今後LoRaWANのサービスを（特に大規模に）提供する場合、よりセキュアなシステムを構築するためにもOTAAの利用が望ましい。サービスによってはまだ安定してOTAAが利用できない場合もあり、利用したいサービスの提供状況や、送信受信における周波数などについてきちんと知らない場合、うまく通信できないこともあるだろう。ご利用の環境をよく調査する必要があるのだ。

本記事がABPとOTAAについて疑問を持っている方の助けになれば幸いだ。

(参考)LoRaWAN Specification v1.1について

公開されている最新版の仕様であるv1.1について、以下のThe Things Networkアンバサダーの方の記事（外部サイト）が参考になる。技術的な詳細ガキになる方は一度目を通して見てもよいだろう。

LoRaWAN v1.1の仕様が公開されました！

セッションキーがどの暗号化に利用されているかなど、詳細に解説してくれている。

また、The Things NeworkにおけるLoRaWANデバイスアドレスの割当など、アドレススペースについても解説されている。

LoRaWAN Address Space

さらに、The Things Networkにて最新のプロトコルスタックであるV3が現在も活発に開発が続けられている。このプロトコルスタックでは新たにLoRaWAN Specification v1.1が実装されている模様だ。

The Things Network Stack for LoRaWAN V3