LoRa無線を利用して２拠点間通信を行う場合、センサーやトラッカー等エンドデバイスの数が数十個までと比較的少ないなら、現場に赴き作業すればなんとか対応できるかもしれません。しかし、エンドデバイスが、数百から1万を超えるデバイス数のような場合、いわゆる中・大規模なIoTシステムを構築するとなるとそうは簡単にはいきません！
そこでLoRaWAN仕様は、エンドデバイスがアップリンクデータを送信する前にアクティベーションまたは参加プロシージャと呼ばれるプロセスを完了する必要があります。エンドデバイスをアクティベートするには、OTAA (Over-The-Air-Activation) または ABP (Activation By Personalization) のいずれかを使用できます。アクティベーションごとに新しいセッションキーが生成されて安全性が高まるため、エンドデバイスのアクティベーションには OTAA を使用することを推奨します。
OTAAを推奨する理由を下記のThe Things Networkホワイトペーパーから見ていくことにしましょう！
＊オリジナルソース ー エンドデバイスのアクティベイション
↓
エンドデバイスのアクティベーション
すべてのエンドデバイスは、メッセージを送受信する前にネットワークに登録する必要があります。この手順はアクティベーションと呼ばれます。利用可能なアクティベーション方法は 2 つあります。
- Over-The-Air-Activation (OTAA) - エンドデバイスにとって最も安全で推奨されるアクティベーション方法。デバイスはネットワークへの参加手順を実行し、その際に動的デバイス アドレスが割り当てられ、セキュリティ キーがデバイスとネゴシエイトされます。
- Activation by Personalization (ABP) - デバイスのアドレスとセキュリティ キーをハードコーディングする必要があります。ABP はOTAA より安全性が低く 、デバイス内のキーを手動で変更しないとネットワーク プロバイダーを切り替えることができないという欠点もあります。
LoRaWAN 1.0.x と 1.1 の参加手順は若干異なります。次の 2 つのセクションでは、LoRaWAN 1.0.x と 1.1 の参加手順を個別に説明します。
LoRaWAN 1.0.x での無線アクティベーション
LoRaWAN 1.0.x では、参加手順ではエンド デバイスとネットワーク サーバー間で 2 つのMAC メッセージを交換する必要があります。
- 参加要求（join-request） - エンドデバイスからネットワークサーバーへ
- 参加承認（join-accept） - ネットワークサーバーからエンドデバイスまで
アクティブ化する前に、AppEUI 、DevEUI 、およびAppKey を エンドデバイスに保存する必要があります。AppKeyは、ルート キー として知られる AES-128 ビットの秘密キーです。エンドデバイスが登録されるネットワーク上に同じAppKeyをプロビジョニングする必要があります。 AppEUIとDevEUI は秘密ではなく、誰でも見ることができます。
注記：
AppKeyがネットワーク経由で 送信されることはありません 。
次の手順では、Over-The-Air-Activation (OTAA) 手順について説明します。
図: LoRaWAN 1.0 の OTAA メッセージ フロー
ステップ1
参加手順は常にエンドデバイスによって開始されます。エンドデバイスは、参加しようとしているネットワークに参加要求メッセージを送信します。 参加要求 メッセージは次のフィールドで構成されます。
| 8バイト | 8バイト | 2バイト |
|---|---|---|
| AppEUI | DevEUI | DevNonce |
- AppEUI – Join-req フレームを処理できるエンティティを一意に識別する、IEEE EUI64 アドレス空間内の 64 ビットのグローバルに一意なアプリケーション識別子。
- DevEUI – エンドデバイスを一意に識別する、IEEE EUI64 アドレス空間内の 64 ビットのグローバルに一意なデバイス識別子。
- DevNonce – エンドデバイスによって生成される一意のランダムな 2 バイト値。ネットワーク サーバーは、各エンドデバイスの DevNonce を使用して、参加要求を追跡します。エンド デバイスが以前に使用した DevNonce を使用して参加リクエストを送信した場合 (この状況はリプレイ攻撃として知られています)、ネットワーク サーバーは参加リクエストを拒否し 、そのエンド デバイスがネットワークに登録することを許可しません。
メッセージ整合性コード (MIC) は、 AppKey を使用して、参加要求メッセージのすべてのフィールドに対して計算されます。計算された MIC は、参加要求メッセージに追加されます。
注記：
AppKeyは参加要求メッセージとともに送信されず、参加要求メッセージは暗号化されません。
参加要求 メッセージは、任意のデータ レートを使用し、地域固有の参加チャネルの 1 つを使用して送信できます。たとえば、ヨーロッパでは、エンド デバイスは 868.10 MHz、868.30 MHz、または 868.50 MHz の中からランダムに選択して参加要求メッセージを送信できます。参加要求メッセージは、1 つ以上のゲートウェイを経由してネットワーク サーバーに送信されます。
ステップ2
ネットワーク サーバーは参加要求メッセージを処理します。ネットワーク サーバーは 2 つのセッション キー (NwkSKey および AppSKey) と、エンドデバイスがネットワークへの参加を許可されている場合は参加承諾メッセージを生成します。
Join**-accept** メッセージは次のフィールドで構成されます。
| 3バイト | 3バイト | 4バイト | 1バイト | 1バイト | 16バイト（オプション） |
|---|---|---|---|---|---|
| AppNonce | ネットID | DevAddr | DL設定 | RXDelay | CFリスト |
- AppNonce – ネットワーク サーバーによって提供されるランダムな値または一意の ID。AppNonce は、2 つのセッション キーAppSKey とNwkSKey を導出するためにエンド デバイスによって使用されます。
- NetID – ネットワーク識別子 (NwkID) の最上位 7 ビットで構成されます。LoRa Allianceで管理運営。
- DevAddr – 現在のネットワーク内のエンド デバイスを識別するためにネットワーク サーバーによって割り当てられる 32 ビットのデバイス アドレス。
- DLSettings – エンドデバイスが使用する必要があるダウンリンク設定で構成される 1 バイトのフィールド。
- RxDelay – TX と RX 間の遅延が含まれます。
- CFList – エンドデバイスが参加しているネットワークのチャネル周波数のオプションのリスト。これらの周波数は地域固有です。
メッセージ****整合性コード (MIC) は、AppKey を使用して参加受け入れメッセージのすべてのフィールドに対して計算されます。計算された MIC は、Join-accept メッセージに追加されます。
その後、 Join**-a** cceptメッセージ自体がAppKey で暗号化されます。ネットワーク サーバーは、ECBモードで AES 復号化操作を使用して、参加受け入れメッセージを暗号化します。
ステップ 3
ネットワーク サーバーは、暗号化された参加承諾 メッセージを通常のダウンリンクとしてエンド デバイスに送り返します。
注記：
参加要求メッセージがネットワーク サーバーによって受け入れられない 場合、エンドデバイスには応答がありません。
ステップ 4
ネットワーク サーバーはNwkSKey を保持し、AppSKey をアプリケーション サーバーに配布します。
ステップ 5
エンドデバイスは、AES 暗号化操作を使用して参加受け入れメッセージを復号化します。エンド デバイスは、AppKey と AppNonceを使用して、ネットワーク セッション キー (NwkSKey) とアプリケーション セッション キー (AppSKey) という2 つのセッション キーを導出します。
これで、エンドデバイスがネットワーク上でアクティブ化されました。
アクティベーション後、次の追加情報がエンドデバイスに保存されます。
- DevAddr - 現在のネットワーク内のエンド デバイスを識別するためにネットワーク サーバーによって割り当てられる 32 ビットのデバイス アドレス。
- NwkSKey - ネットワーク セッション キーは、メッセージの整合性を確保するために、エンド デバイスとネットワーク サーバーによってすべてのデータ メッセージのメッセージ整合性コード (MIC) を計算および検証するために使用されます。NwkSKey は、MAC コマンドでペイロードを暗号化および復号化するためにも使用されます。
- AppSKey - アプリケーション セッション キーは、メッセージの機密性を確保するために、データ メッセージ内のアプリケーション ペイロードの暗号化と復号化に使用されます。
LoRaWAN 1.1 での無線アクティベーション
LoRaWAN 1.0.x では、参加手順では、エンド デバイスと参加サーバーの間で 2 つの MAC メッセージを交換する必要があります。
- 参加リクエスト（join-request） - エンドデバイスから参加サーバーへ
- 参加承認（join-accept） - 参加サーバーからエンドデバイスまで
アクティブ化する前に、JoinEUI 、DevEUI 、AppKey 、およびNwkKey をエンドデバイスに保存する必要があります。AppKeyとNwkKey は、ルート キー として知られる AES-128 ビットの秘密キーです。一致するAppKey 、NwkKey 、およびDevEUI は 、参加手順とセッション キーの導出の処理を支援する参加サーバーにプロビジョニングする必要があります。JoinEUIとDevEUI は秘密ではなく、誰でも見ることができます。
注記：
AppKeyとNwkKey がネットワーク経由で送信されることはありません。
次の手順では、Over-The-Air-Activation (OTAA) 手順について説明します。
図: LoRaWAN 1.1 の OTAA メッセージ フロー
ステップ1
参加手順は常にエンドデバイスによって開始されます。エンドデバイスは、参加しようとしているネットワークに参加****要求メッセージを送信します。参加要求 メッセージは次のフィールドで構成されます。
| 8バイト | 8バイト | 2バイト |
|---|---|---|
| EUIに参加する | DevEUI | DevNonce |
- JoinEUI –参加リクエストの処理とセッション キーの導出を支援できる参加サーバーを一意に識別する、IEEE EUI64 アドレス空間の 64 ビット グローバル アプリケーション識別子。
- DevEUI – エンドデバイスを一意に識別する、IEEE EUI64 アドレス空間の 64 ビットのグローバル デバイス識別子。
- DevNonce – デバイスに最初に電源が投入されたときに 0 から始まり、 Join-request ごとに増加する 2 バイトのカウンター。DevNonce 値は、リプレイ攻撃 を防ぐために使用されます。
注記：
LoRaWAN 1.1 では、AppEUI はJoinEUIに置き換えられます。
MIC は、 NwkKeyを使用して、参加要求メッセージのすべてのフィールドにわたって計算されます。計算された MIC は、参加要求メッセージに追加されます。
注記：
NwkKeyは参加要求メッセージとともに送信されず、参加要求メッセージは暗号化されず、プレーン テキストとして送信されます。
参加要求メッセージは、任意のデータ レートを使用し、地域固有の参加チャネルの 1 つを使用して送信できます。たとえば、ヨーロッパでは、エンド デバイスは 868.10 MHz、868.30 MHz、または 868.50 MHz の中からランダムに選択して参加要求メッセージを送信できます。参加要求 メッセージは、1 つ以上のゲートウェイを経由してネットワーク サーバーに送信されます。
注記：
参加要求が受け入れられない 場合、エンドデバイスには応答がありません。
ステップ2
ネットワーク サーバーは、参加要求メッセージを対応する参加サーバーに転送します。
ステップ 3
参加サーバーは、参加要求メッセージを処理します。エンドデバイスがネットワークへの参加を許可されている場合、参加サーバーはすべてのセッションキー (AppSKey、FNwkSIntKey、SNwkSIntKey、および NwkSEncKey) を生成します。
ステップ 4
上記の手順が成功すると、ネットワーク サーバーは参加承諾 メッセージを生成します。Join-accept メッセージは次のフィールドで構成されます。
| 1バイト | 3バイト | 4バイト | 1バイト | 1バイト | 16バイト |
|---|---|---|---|---|---|
| 参加ノンス | ネットID | DevAddr | DL設定 | RXDelay | CFリスト |
- JoinNonce – 参加サーバーによって提供され、セッション キー FNwkSIntKey 、SNwkSIntKey 、NwkSEncKey 、およびAppSKey を導出するためにエンド デバイスによって使用されるデバイス固有のカウンター値。
- NetID – 24 ビットの一意のネットワーク識別子。
- DevAddr – 現在のネットワーク内のエンド デバイスを識別するためにネットワーク サーバーによって割り当てられる 32 ビットのデバイス アドレス。
- DLSettings – エンドデバイスが使用する必要があるダウンリンク設定で構成される 1 バイトのフィールド。
- RxDelay – TX と RX 間の遅延が含まれます
- CFList – エンドデバイスが参加しているネットワークのチャネル周波数のオプションのリスト。これらの周波数は地域固有です。
メッセージ整合性コード (MIC) は、NwkKey (LoRaWAN 1.0 デバイスの場合) または JSIntKey (LoRaWAN 1.1 デバイスの場合) を使用して、Join-accept メッセージのすべてのフィールドにわたって計算されます。計算された MIC は、Join-accept メッセージに追加されます。
その後、Join-accept メッセージ自体が NwkKey で暗号化されます。ネットワーク サーバーは、ECB モードで AES 復号化操作を使用して、参加受け入れメッセージを暗号化します。
Join**-acceptメッセージは** 、NwkKey (Join-request によってトリガーされた場合) またはJSEncKey (Rejoin-request によってトリガーされた場合)を使用して暗号化されます。
次に、ネットワーク サーバーは、暗号化された参加承諾メッセージを通常のダウンリンクとしてエンド デバイスに送り返します。
注記：
参加要求メッセージがネットワーク サーバーによって受け入れられない 場合、エンドデバイスには応答がありません。
ステップ 5
参加サーバーは、AppSKey をアプリケーション サーバーに送信し、3 つのネットワーク セッション キー (FNwkSIntKey、SNwkSIntKey、および NwkSEncKey) をネットワーク サーバーに送信します。
ステップ6
エンドデバイスは、AES 暗号化操作を使用して参加受け入れメッセージを復号化します。エンドデバイスは、AppKey、NwkKey、および JoinNonce を使用してセッション キーを生成します。
LoRaWAN 1.0.x デバイスの場合、
- AppSKey は NwkKey から派生します。
- FNwkSIntKey、SNwkSIntKey、および NwkSEncKey は NwkKey から派生します。
LoRaWAN 1.1 デバイスの場合、
- AppSKey は AppKey から派生します。
- FNwkSIntKey、SNwkSIntKey、および NwkSEncKey は NwkKey から派生します。
これで、エンドデバイスがネットワーク上でアクティブ化されました。
アクティベーション後、次の追加情報がエンドデバイスに保存されます。
- DevAddr - 現在のネットワーク内のエンド デバイスを識別するためにネットワーク サーバーによって割り当てられる 32 ビットのデバイス アドレス。
- FNwkSIntKey - メッセージの整合性を確保するために、すべてのアップリンク データ メッセージの MIC (部分的) を計算するためにエンド デバイスによって使用されるネットワーク セッション キー。
- SNwkSIntKey - メッセージの整合性を確保するために、エンド デバイスがすべてのアップリンク データ メッセージの MIC (部分的) を計算し、すべてのダウンリンク データ メッセージの MIC を計算するために使用されるネットワーク セッション キー。
- NwkSEncKey - メッセージの機密性を確保するために、アップリンクおよびダウンリンク データ メッセージの MAC コマンドでペイロードを暗号化および復号化するために使用されるネットワーク セッション キー。
- AppSKey - メッセージの機密性を確保するために、データ メッセージ内のアプリケーション データを暗号化および復号化するためにアプリケーション サーバーとエンド デバイスの両方で使用されるセッション キー。
パーソナライゼーションによるアクティベーション
パーソナライゼーションによるアクティベーション (ABP) は、無線アクティベーション手順をバイパスして、エンドデバイスを事前に選択されたネットワークに直接結び付けます。Personalization によるアクティベーションは**、安全性が低いアクティベーション方法**であり、デバイスのキーを手動で変更しないとネットワーク プロバイダーを切り替えることができないという欠点もあります。参加サーバーは ABP プロセスには関与しません。
ABP 方式を使用してアクティブ化されたエンド デバイスは、単一のネットワークでのみ動作し、その存続期間全体にわたって同じセキュリティ セッションを維持します。
LoRaWAN 1.0.x でのパーソナライゼーションによるアクティベーション
DevAddrと 2 つのセッション キーNwkSKey およびAppSKey は、DevEUI、AppEUI、AppKey****の 代わりにエンドデバイスに直接保存されます。各エンドデバイスには、NwkSKey と AppSkey の一意のセットが必要です。同じDevAddr とNwkSKey を ネットワーク サーバーに保存し、AppSKey をアプリケーション サーバーに保存する必要があります。
図: LoRaWAN 1.0 での ABP の DevAddr キーとセッション キーの事前共有
LoRaWAN 1.1 のパーソナライゼーションによるアクティベーション
DevAddrと 4 つのセッション キーFNwkSIntKey 、SNwkSIntKey 、NwkSEncKey 、およびAppSKey は****、 DevEUI、JoinEUI、AppKey、および NwkKey の代わりにエンド デバイスに直接保存されます。同じDevAddr 、 FNwkSIntKey 、SNwkSIntKey 、およびNwkSEncKey を ネットワーク サーバーに保存し、AppSKey を アプリケーション サーバーに保存する必要があります。
図: LoRaWAN 1.1 での ABP の DevAddr キーとセッション キーの事前共有
質問
- 安全なアクティベーション方法ではないものは何ですか?
- 無線アクティベーション (OTAA)
- パーソナライゼーションによるアクティベーション (ABP)
- 最も安全なアクティベーション方法は何ですか?
- 無線アクティベーション (OTAA)
- パーソナライゼーションによるアクティベーション (ABP)
- LoRaWAN 1.1 の ABP ではどのセキュリティ キーをエンドデバイスに保存する必要がありますか?
- FNwkSIntKey、SNwkSIntKey、NwkSEncKey、AppSKey
- NwkSKey、AppSKey
- JSIntKey、JSEncKey
- LoRaWAN 1.0.x の ABP ではどのセキュリティ キーをエンドデバイスに保存する必要がありますか?
- FNwkSIntKey、SNwkSIntKey、NwkSEncKey、AppSKey
- NwkSKey、AppSKey
- JSIntKey、JSEncKe