LoRaWANのセキュリティ/サイドチャネル攻撃の可能性と対策について考えてみる

前提

• LoRaWANはいくら通信を暗号化しているとはいえ、空間上にブロードキャストされてしまう以上、事実上の傍受が簡単
  • 単なる受信をするだけでLoRaWAN通信を得ることができる = そのLoRaWANネットワークの参加者である必要がない
  • もちろんそれなりのHW = 傍受を狙ったLoRaWANゲートウェイを用意して、敢えてそういう行動に出たら、の話だが
• 暗号化されているのはデータペイロードのみであり、メタデータ部分は暗号化されていない
  • ユーザー任意のデータペイロード = FRMPayload
  • LoRaWANのフレーム構造上、DevAddr、FCtrl、FCnt、FPort、MIC等の“メタデータ”は暗号化されず空間中を流れる
• これらの 暗号化されていない、あるいは副次的に観測可能な情報 を利用して、通信の性質やデバイスの状態・行動を推測する手法は、一般に サイドチャネル攻撃 と呼ばれる
  • 本記事で扱うのは、暗号そのものを破る攻撃ではなく、主にLoRaおよびLoRaWAN由来のメタデータや物理層の情報から何が推測できるのか、どういった現実的な攻撃があり得るのか？という部分である
• これらの事実に対してどういう対策が考えられるか？検討してみる

先に結論 (対策案)

ここで言及している手法は、電池寿命・匿名性・実装コストの三角関係になり、バランス取りが重要になる。全部やれるケースはまずないだろう。やればやるほどLoRaWANとしての旨味をどんどん失っていく。そのシステム構成やビジネス的価値を踏まえ、いくつかの手法をチョイス → 組み合わせていくのが現実的である。

例えば、イベント性が高い用途ではジッターとサイズ平準化を優先し、電池寿命が重要な用途においては最小限の対策に留める… などの割り切りや落とし所を見つける必要があるだろう。

OTAA方式でLoRaWANネットワークへJOINさせ一時鍵で通信させる

問題

• LoRaWANには大きく分けてABPとOTAAという2種類の参加方式がある
  • ABPの場合は、鍵を事前にデバイス内部に持っておき、これらの固定鍵を持って暗号化と認証を行う
  • OTAAの場合は、JOINの度に一時的な鍵 = セッション鍵が生成され、そのセッション鍵で以後の通信を保護する
• ABPは固定鍵を使い回すため漏洩時の影響が大きい
• OTAAの場合は一時的な鍵 = セッション鍵でのみやりとりをするため相対的にセキュリティ的には強くなる

対策

• OTAAしか使わないようにする
  • またOTAAの古いバージョンは既にセキュリティ的な既知の問題が存在するため、原則 1.0.3以上、可能なら1.0.4を使うこと
  • まだ市場では非常に少ないが、さらにセキュリティ強化された v1.1 が使えるなら是非そうすること
• JOINしたあとそのまま長い時間使い続けない
  • 定期/不定期に意図的にJOINし直すことでセッション鍵を更新させる
  • 一方でJOINは電力を食いがちな行為であるため、やり過ぎには注意
  • DevNonceの管理に注意 (フラッシュメモリで管理するなど)

---

送信タイミングをランダムに行う（ジッターの導入）

問題

• LoRaWANのペイロード自体は暗号化されていても、送信時刻や送信周期は観測者に見える
  • メタデータ／トラフィック解析 が可能
• その結果、観測者が「このデバイスはいつ活動したか」「特定イベント時にだけ送るのではないか」を推測できる可能性がある。
• 特に イベント駆動（例：XXが発生したら送信） のような設計だと、送信時刻 ＝イベント時刻の近似になり、推測が容易になり得る。

対策

• イベント発生から送信までの間に ランダムな遅延（ジッター） を入れ、送信時刻とイベント時刻の相関を弱める。
  • 例：数十秒〜数分の範囲でランダム遅延（用途の許容レイテンシに合わせて設計）
• ジッター生成に使う乱数は、予測困難な乱数源（十分なエントロピーのある乱数）を使う。
• ただし、ジッターの導入は 通知遅延（UX） と 送信回数・再送挙動（電池消費） に影響し得るため、要件とトレードオフで決める。

ダミー送信の挿入（カバートラフィック）

問題

• 送信頻度が低い、あるいは「特定イベント時だけ送る」場合、観測者にとって 送信＝意味のあるイベント になりやすい。
• 送信時刻の偏りが大きいほど、行動推測（在宅推定、イベント推定など）が成立しやすい。

対策

• ランダムなタイミングで ダミー（意味のない）送信 を混ぜ、イベント送信と区別しにくくする。
  • ダミーは受信側（アプリ層）で識別して破棄できる形式にする
  • 暗号化されているデータペイロードに“ダミー種別”を入れてアプリ側でそこを見て早期に破棄するなど
• ただしやればやるほど、消費電力が増すことになる
  • またそもそも、地域・運用条件によって 送信制限（デューティサイクル等） や 空中時間（ToA）コスト も厳しくなってくる
  • 単にダミー送信をしまくればいいというわけでなく、それらのパラメーターも踏まえた上での運用設計が必要

アプリ層フラグメンテーション＋パディングによるサイズ平準化

問題

• 暗号化されていても、観測者は データレートや空中時間（ToA）などから、ペイロード長の“レンジ”を推定 できる可能性がある。
• ペイロード長がイベント種類と強く結びつく設計（例：重要イベントは長い、大したことないイベントは短い）だと、サイズ情報がサイドチャネルになり得る。

対策

• アプリ層でペイロードサイズを 一定（または少数の固定サイズ）に揃える。
  • 例：常に 50Byte に揃える、短いメッセージにはパディング、長いメッセージは分割（フラグメンテーション）する
• 可能なら「サイズを完全固定」ではなく、いくつかのバケット（例：32/48/64B） に寄せる方式も選択肢（コストと匿名性のバランス）。
• ただし、サイズ平準化はToAが増えがちで、電池・スループット・規制に直接的に影響する
  • 他の手法とも組み合わせた上でバランスを取る必要がある

送信出力を意図的に下げて傍受範囲を小さくする

問題

• LoRaの受信は、正規のゲートウェイ以外でも受信機材を用意すれば成立し得るため、攻撃者が受信できる範囲が広いほど傍受リスクは増える。
• また複数地点で受信されると、RSSIの観測および比較から、そのデバイスの位置推定などが可能になる恐れがある

対策

• 通信が成立する範囲で、送信出力を 必要最小限 に寄せる
  • いわゆる“過剰到達”を避ける
• ただし、送信出力低下は 通信成功率の悪化→再送増→結果的に観測機会増 につながる場合がある
  • 出力を下げ過ぎて成功率が落ちると、再送やJoin再試行が増え、結果として消費電力に悪い影響を与えやすい
• さらに、攻撃者の受信環境（高利得アンテナ等）次第では、出力低下だけで傍受を防げる保証はないため、他対策（ジッター・サイズ平準化等）と組み合わせることを前提にしたほうがいい

※「RSSIの変化を生ませて位置特定を困難に」は、常に成立するとは言いにくいので、記事では「限定的」くらいの扱いが安全です。

固定的なSpreading Factorを使わない / 意図的に変更してごまかす

問題

• Spreading Factor（SF）やデータレートは観測可能であり、固定だと「このデバイスはいつもこのSF」という特徴量になり得る。
  • そしてこれもまたRSSIと組み合わせて、位置推定の材料になりえる

対策

• 観測可能な特徴量（いつも同じSF/DR）の情報をエラス
• 例えば、「本当はSF7でよいのだが敢えてSF10で送信する」など観測者を混乱させるようなごまかしを入れる
  • もちろんそもそもSF12じゃないと無理であるため、ごまかしができない…といったこともあると思う
  • そのときは仕方ない
• ただしやりすぎると、パケットロスや再送が増える可能性になりかねない
  • そうなると、むしろ観測者にとって特徴が強まる場合があるため、副作用（再送増・電池増）とのバランス取りが必要
• これ単体では効果は薄いため、本対策は過信せず、他手法との組み合わせを前提にすること

DevEUI / JoinEUI を意図的に変化させてごまかす

問題

• OTAA時のJoin-requestではDevEUI/JoinEUIが見え得る
  • 「デバイスIDが見える」こと自体はトラフィック解析上の材料になり得る。
• DevEUIは多くの場合、プロビジョニングや運用（登録・認可・監査）で 恒久識別子として扱われる。
• 他、データレートやRSSI, ペイロードサイズなどから「このデバイスが大体この位置にいてこういうイベントが発生した」といった位置と行動の推定の恐れがある
  • 「この DevEUI = 同一デバイス」→ 時系列で位置・行動を結び付けられる可能性がある

対策

• 定期/不定期にEUIを変更し、観測者からして短期的には別デバイスに見せかける
• LNSおよびそれを管理するアプリケーション側の制御を大前提に、定期/不定期にDevEUIやJoinEUIを意図的に変化させてごまかす
  • 一部のLoRaチップであればDevEUI / JoinEUIは静的なものでなく更新ができる場合がある
  • 私が触ったことがあるLoRaチップの場合は全部できた
  • とはいえ、運用中に突然変えてしまうとジョインができずに死ぬ
• そのため、LNS管理側とFW側の双方の実装によって、ある一定周期で次のEUI情報を交換 → 問題なければ、次からその情報を使ってジョインし直す といったことを行う
  • LNS管理側では、デバイス側からOKをもらったら新しいDevEUIやJoinEUIをLNSに登録する
  • 期日をこえて、新しいDevEUIでの通信が確立することが確実になったら古い登録を削除する
• 例えば同じEUIを使う期間が1週間だとすれば、5日経過時点で次のEUI情報をデータペイロードに入れて交換
  • • データペイロードは暗号化されているため、EUIの次候補や切替情報の「内容」自体は観測者にバレない
  • デバイス側FWでそれを認識し、いついつからこれを使う というのが理解できたらLNS側にACKを返す
  • LNS管理側においては、そのACKを持ってデバイス側でも認識してくれたと判断し、新しいEUI情報を先に登録しておく
  • 期日を超えて新しいEUIで接続確立できたら古いEUI登録を削除する
• ただし、この手法だけでは結局 他の特徴量をもって、「あ、リネームしただけだな」と見破られる可能性が十分にある
  • よって、主対策ではなく、他の手法と併用する補助的な錯乱策として位置付けて検討すべき
  • 一方で、一連のシステムの実装コストが非常に高く、そのコストバランスを考えると、この手法を率先して選ぶ必要はないかもしれない

参考文献

仕様・前提

• LoRa AllianceのSecurity Whitepaper
  • 仕様の設計思想・鍵体系・責務分離の一次ソース
  • そもそもの暗号の前提知識、LoRaWANにおいて何が秘匿で何が秘匿でないか？がわかる
• Analysis of LoRaWAN 1.0 and 1.1 Protocols Security
  • OTAA v1.0/v1.1のキー生成・互換性や差分を説明
  • OTAAおよび各種バージョンでどんなことが行われているのか、差があるのかの理解に役立つ

実環境トラフィックの観測

• Explorning LoRaWAN Traffic
  • いろんな都市でスニッファ使ってLoRaWAN通信を収集・解析した論文
  • 実測ベースでどんなデータを集められるのか、どんなパターンが見えてくるのかというのがわかる
  • ちなみに「デフォルト/露出キーなど基本原則違反、Duty-Cycle違反、Class-Bビーコン不整合などセキュリティに限らず、そもそも間違った運用がされているケースも見つけており非常に面白い

メタデータ・トラフィック解析によるプライバシー侵害

• Discovery privacy threats via device de-anonymization in LoRaWAN
  • DevAddrと通信パターンからDevEUIを導き出す攻撃手法の研究
  • 確率的にDevEUI（またはデバイス固有ID）との対応付けが可能であることを示した (実際に成功)
• Privacy leakage of LoRaWAN smart parking occupancy sensors
  • LoRaWAN駐車センサーの送信パターンから駐車場の状態をサイドチャネル攻撃で推測可能であることを実証

物理層・ハードウェア起因レベルの攻撃可能性

• A Comprehensive Survey on Deep Learning-Based LoRa Radio Frequency Fingerprinting Identification

  • LoRaWANではなくLoRa物理層のRFFI（Radio Frequency Fingerprinting Identification）をサーベイし、LoRa固有のハードウェア起因の癖を研究
  • それらの癖からノードを特定する手法の研究
  • 単なるメタデータの解析ではなく物理的な電波のにじみすらもノード特定の要素になりうる点を指摘

• Evaluation of Side-Channel Key-Recovery Attacks on LoRaWAN End-Device

  • LoRaWANノード近傍のEMリークからLoRawWAN v1.0のAppKeyとv1.1のNwkKeyを復元できることを実証
  • ただし、近傍攻撃 = 物理的にかなり近づくのが前提である点に注意

• LoRaWAN Physical Layer-Based Attacks and Countermeasures, A Review

  • 主に物理面での攻撃手法についての研究
  • 電波に対する直接的なジャミングやリプレイなど

• Selective jamming of LoRaWAN using commodity hardware

  • LoRaWAN の物理層に対する 選択的ジャミング（Selective Jamming） の実装・評価を行った研究。
  • パケットをリアルタイムに識別し、特定のフレームだけを妨害することで通信を阻害する手法を示している。
  • さらに、こうしたジャミング攻撃に対する緩和策の可能性についても示唆

• Impact of Reactive Jamming Attacks on LoRaWAN: a Theoretical and Experimental Study

  • LoRaWAN がジャミング攻撃に対してどの程度脆弱であるかを、理論解析と実験の両面から示した研究。
  • 特定のシンボル数や送信パワーで妨害信号を放つことで、フレーム成功率が低下することを定量的に評価している。
  • LoRa の preamble が容易に観測できるため、低コスト SDR を使った妨害が実質的に可能である点を示している。

その他

• A Systematic Review of Security in the LoRaWAN Network Protocol
  • LoRaWAN バージョン1.0や1.1のときに存在した脆弱性とその対策の考察
  • その上で、改善策やチェック/テスト方法まで含めて整理してくれている

論文からの総括

• デバイスの活動スケジュール… つまり送信周期・時刻、確認応答の有無（ACK/Confirmed）などから高い確率で何らかの特徴的な行動が推測できる可能性がある
  • 例えば、「今、家に帰ってきたかもしれない」が推測できるかもしれない
• LoRaの空中時間（ToA）とデータレートの情報から、ペイロード長レンジを推定可能
  • 完全一致ではないが高精度に推測できる
  • そこからさらにどんなものが流れているのか？を推測できる
  • うちでいえば解施錠イベント送信なのか、ログ送信なのか、みたいな
• デバイスの同定・再識別
  • DevAddrの変化と送信タイミングの癖、OTAAのJoin-requestで見えるDevEUI、RFフィンガープリント等の組合せで“誰の電波か”を絞り込める
• ToAとRSSIの情報（特に複数観測点がある場合）から、デバイスがどこにいるか？の推測でき得る可能性がある
  • デバイスがわかっていて、さらに大体どのへんにいるのかがわかり、さらに何らかの重要そうなイベント… 家に帰ったきた、家から出ていった などがわかるかもしれない
• これらは暗号そのものの直接的な破綻ではなく、LoRaおよびLoRaWAN由来のメタデータおよび物理層を対象としたサイドチャネル的な情報漏えいであるといえる