فعال‌سازی LoRaWAN: روش‌های OTAA و ABP در نسخه‌های 1.0.x و 1.1

پیش تر به بررسی کلاس دستگاه های LoRaWAN پرداختیم. هر دستگاه‌ LoRaWAN برای اینکه بتونه پیام بفرسته یا دریافت کنه، باید توی یک شبکه ثبت بشه. به این فرآیند فعال‌سازی (Activation) گفته میشه. برای این کار دو روش وجود داره:

۱. فعال‌سازی از راه دور (Over-The-Air Activation – OTAA)

 این روش امن‌ترین و همین‌طور روش پیشنهادی برای فعال‌سازی دستگاه‌هاست. در OTAA، دستگاه یک فرآیند join رو با شبکه انجام میده. طی این فرآیند، یک آدرس پویا (Dynamic Device Address) به دستگاه اختصاص داده میشه و کلیدهای امنیتی هم بین دستگاه و شبکه مذاکره و تنظیم میشن.

۲. فعال‌سازی دستی (Activation By Personalization – ABP)

اینجا برعکس OTAA، آدرس دستگاه و کلیدهای امنیتی باید به‌صورت دستی داخل دستگاه کدنویسی یا همون hardcode بشن. این روش امنیت کمتری نسبت به OTAA داره. از طرف دیگه، یک محدودیت مهم هم داره: دستگاهی که با ABP فعال‌سازی شده، نمی‌تونه به راحتی شبکه رو تغییر بده؛ مگر اینکه کلیدها و آدرس توی خود دستگاه به‌صورت دستی عوض بشن.

نکته پایانی اینکه فرآیند join برای نسخه‌های مختلف LoRaWAN کمی فرق می‌کنه. به‌طور خاص بین نسخه 1.0.x و 1.1 تفاوت‌هایی وجود داره که باید جداگانه توضیح داده بشن.

فعال‌سازی از راه دور در LoRaWAN نسخه 1.0.x

در نسخه 1.0.x از LoRaWAN، فرآیند join یا همون فعال‌سازی با تبادل دو پیام MAC بین دستگاه و سرور شبکه انجام میشه:

• Join-request: از طرف دستگاه به سرور شبکه ارسال میشه.
• Join-accept: پاسخی هست که از طرف سرور شبکه به دستگاه داده میشه.

قبل از اینکه فعال‌سازی شروع بشه، چند داده باید داخل دستگاه ذخیره شده باشه:

• AppEUI و DevEUI که شناسه‌های دستگاه و اپلیکیشن هستن. این‌ها محرمانه نیستن
• AppKey که یک کلید ۱۲۸ بیتی AES و به‌عنوان کلید ریشه (Root Key) شناخته میشه. این کلید فقط بین دستگاه و شبکه مشترک هست و باید از قبل روی هر دو Provision بشه.

نکته خیلی مهم اینه که AppKey هیچ‌وقت روی شبکه ارسال نمیشه. یعنی امنیت اصلی OTAA همین‌جاست؛ کلید ریشه همیشه محفوظ می‌مونه و فقط برای تولید کلیدهای جلسه (Session Keys) استفاده میشه.

گام اول در فرآیند Join (LoRaWAN 1.0.x)

فرآیند join همیشه از سمت دستگاه شروع میشه. دستگاه یک پیام Join-request به شبکه‌ای که می‌خواد بهش متصل بشه ارسال می‌کنه. این پیام شامل سه بخش اصلیه:

• AppEUI: یک شناسه ۶۴ بیتی منحصربه‌فرد در فضای آدرس IEEE EUI64 که اپلیکیشنی رو مشخص می‌کنه که می‌تونه درخواست Join رو پردازش کنه.
• DevEUI: یک شناسه ۶۴ بیتی منحصربه‌فرد که خود دستگاه رو در فضای آدرس IEEE EUI64 مشخص می‌کنه.
• DevNonce: یک مقدار ۲ بایتی تصادفی و یکتا که توسط دستگاه تولید میشه. سرور شبکه از DevNonce استفاده می‌کنه تا مطمئن بشه درخواست Join تکراری نیست. اگر دستگاه یک DevNonce تکراری بفرسته (که بهش حمله Replay می‌گن)، سرور Join-request رو رد می‌کنه و اجازه ثبت‌نام نمی‌ده.

برای اینکه امنیت تضمین بشه، یک Message Integrity Code (MIC) روی همه این فیلدها محاسبه میشه. این MIC با استفاده از AppKey تولید میشه و بعد به پیام Join-request اضافه میشه.

✅نکته مهم

پیام Join-request می‌تونه با هر نرخ داده‌ای (Data Rate) و از طریق یکی از کانال‌های مخصوص فعال‌سازی (join channels) ارسال بشه. مثلاً در اروپا دستگاه می‌تونه به صورت تصادفی یکی از فرکانس‌های 868.10 MHz، 868.30 MHz یا 868.50 MHz رو انتخاب کنه. بعد این پیام از طریق یک یا چند گیت‌وی به سرور شبکه منتقل میشه.

گام دوم در فرآیند Join (LoRaWAN 1.0.x)

بعد از اینکه سرور شبکه پیام Join-request رو دریافت و بررسی کرد، اگر دستگاه مجاز به ورود به شبکه باشه، دو کلید جلسه (Session Keys) تولید می‌کنه:

• NwkSKey برای ارتباطات شبکه
• AppSKey برای داده‌های اپلیکیشن

همچنین یک پیام Join-accept برای دستگاه آماده و ارسال می‌کنه. این پیام شامل فیلدهای زیره:

• AppNonce: یک مقدار تصادفی یا شناسه یکتاست که از طرف سرور شبکه تولید میشه. دستگاه از AppNonce به همراه AppKey برای مشتق‌سازی دو کلید جلسه (AppSKey و NwkSKey) استفاده می‌کنه.
• NetID: شامل شناسه شبکه (NwkID) هست که ۷ بیت پرارزش (MSB) رو تشکیل میده.
• DevAddr: یک آدرس ۳۲ بیتی که توسط سرور شبکه به دستگاه اختصاص داده میشه تا توی شبکه شناسایی بشه.
• DLSettings: یک فیلد یک بایتی شامل تنظیمات مربوط به پیام‌های downlink که دستگاه باید ازشون استفاده کنه.
• RxDelay: مدت زمان تأخیر بین ارسال (TX) و دریافت (RX) رو مشخص می‌کنه.
• CFList: یک لیست اختیاری از فرکانس‌های کانال که دستگاه می‌تونه ازشون استفاده کنه. این لیست وابسته به منطقه جغرافیاییه.

برای حفظ امنیت، یک Message Integrity Code (MIC) روی تمام این فیلدها با استفاده از AppKey محاسبه میشه و به پیام Join-accept اضافه میشه.

نکته مهم‌تر اینه که خود پیام Join-accept رمزگذاری میشه. سرور شبکه برای رمزگذاری این پیام از الگوریتم AES در حالت ECB استفاده می‌کنه. جالب اینجاست که برخلاف همیشه، اینجا از عملیات Decrypt در AES-ECB استفاده میشه تا پیام Join-accept رمزگذاری بشه 🙂. آره میدونم یکم عجیبه ولی هست دیگه.

گام سوم در فرآیند Join (LoRaWAN 1.0.x)

وقتی سرور شبکه پیام Join-accept رو آماده و رمزگذاری کرد، اون رو مثل یک پیام downlink عادی برای دستگاه می‌فرسته. دستگاه این پیام رو دریافت می‌کنه، رمزگشایی انجام میده و بر اساس اطلاعات داخلش (مثل AppNonce، NetID و DevAddr) کلیدهای جلسه خودش رو تولید می‌کنه. از این لحظه به بعد، دستگاه به‌طور کامل عضو شبکه شده و می‌تونه ارتباط امن برقرار کنه.

نکته مهم اینجاست که اگر سرور شبکه تصمیم بگیره پیام Join-request رو نپذیره، هیچ پاسخی به دستگاه ارسال نمی‌کنه. یعنی در عمل سکوت سرور به معنای رد شدن درخواست دستگاهه.

گام چهارم در فرآیند Join (LoRaWAN 1.0.x)

وقتی پیام Join-accept پردازش شد و دستگاه عضو شبکه شد، سرور شبکه کلیدهای جلسه رو مدیریت می‌کنه. کلید NwkSKey (کلید شبکه) پیش خودش نگه داشته میشه تا برای اعتبارسنجی و مدیریت پیام‌های مربوط به شبکه استفاده بشه. در عوض، کلید AppSKey (کلید اپلیکیشن) به سرور اپلیکیشن منتقل میشه. اینطوری داده‌هایی که دستگاه‌ها می‌فرستن فقط توسط همون اپلیکیشن مقصد قابل رمزگشایی هستن، نه توسط اپراتور شبکه.

این تفکیک باعث میشه شبکه بتونه multi-tenant باشه؛ یعنی یک اپراتور بتونه سرویس رو به چند شرکت یا اپلیکیشن مختلف بده، بدون اینکه خودش دسترسی به داده‌های واقعی اون‌ها داشته باشه.

گام پنجم در فرآیند Join (LoRaWAN 1.0.x)

وقتی دستگاه پیام Join-accept رو دریافت کرد، با استفاده از الگوریتم AES (در حالت encrypt) اون رو رمزگشایی می‌کنه. در این مرحله دستگاه با استفاده از AppKey و مقدار AppNonce، دو کلید جلسه خودش رو مشتق‌سازی می‌کنه:

• NwkSKey یا Network Session Key
• AppSKey یا Application Session Key

از این لحظه به بعد، دستگاه رسماً روی شبکه فعال (Activated) شده و آماده برقراری ارتباط امنه.

بعد از فعال‌سازی، چند اطلاعات مهم جدید هم داخل دستگاه ذخیره میشه:

• DevAddr: یک آدرس ۳۲ بیتی که توسط سرور شبکه اختصاص داده میشه تا دستگاه رو درون شبکه شناسایی کنه.
• NwkSKey: این کلید برای محاسبه و بررسی Message Integrity Code (MIC) همه پیام‌های داده استفاده میشه تا یکپارچگی پیام‌ها تضمین بشه. علاوه بر اون، برای رمزگذاری و رمزگشایی بارهای حاوی دستورات MAC هم به کار میره.
• AppSKey: این کلید برای رمزگذاری و رمزگشایی داده‌های اپلیکیشن داخل پیام‌ها استفاده میشه و نقش اصلیش حفظ محرمانگی داده‌هاست.

به این ترتیب، دستگاه هم آدرس خودش رو در شبکه می‌گیره و هم کلیدهای امنیتی لازم رو. نتیجه این میشه که هم یکپارچگی داده‌ها و هم محرمانگی اون‌ها تضمین میشه، بدون اینکه کلید ریشه (AppKey) هیچ‌وقت روی شبکه جابه‌جا شده باشه.

فعال‌سازی از طریق هوا در LoRaWAN نسخه 1.1

در LoRaWAN نسخه 1.0.x، فرآیند join شامل تبادل دو پیام MAC بین دستگاه و سرور شبکه بود: Join-request و Join-accept. اما در نسخه 1.1 یک تغییر مهم ایجاد شده و این فرآیند حالا بین دستگاه انتهایی و Join Server انجام میشه.

قبل از شروع فعال‌سازی، چند داده باید داخل دستگاه ذخیره بشن:

• JoinEUI و DevEUI: شناسه‌های منحصربه‌فرد برای اپلیکیشن و دستگاه. این‌ها محرمانه نیستن و همه می‌تونن ببیننش.
• AppKey و NwkKey: هر دو کلیدهای محرمانه ۱۲۸ بیتی (AES-128) هستن که به‌عنوان کلیدهای ریشه (Root Keys) شناخته می‌شن.

برای اینکه فرآیند درست انجام بشه، همین AppKey، NwkKey و DevEUI باید از قبل روی Join Server هم Provision بشن، چون این سرور مسئول پردازش درخواست Join و تولید کلیدهای جلسه (Session Keys) هست.

نکته مهم اینه که درست مثل نسخه قبلی، AppKey و NwkKey هیچ‌وقت روی شبکه ارسال نمی‌شن. این کلیدها فقط روی دستگاه و Join Server باقی می‌مونن و امنیت اصلی LoRaWAN 1.1 رو تضمین می‌کنن.

گام اول در فرآیند Join (LoRaWAN 1.1)

همون‌طور که در نسخه قبلی هم بود، فرآیند join همیشه از سمت دستگاه شروع میشه. دستگاه یک پیام Join-request به شبکه‌ای که می‌خواد بهش متصل بشه ارسال می‌کنه. این پیام شامل سه بخش اصلیه:

• JoinEUI: یک شناسه ۶۴ بیتی در فضای آدرس IEEE EUI64 که به شکل یکتا سرور Join رو مشخص می‌کنه. این همون سروریه که بعداً در پردازش درخواست Join و تولید کلیدهای جلسه کمک می‌کنه.
• DevEUI: یک شناسه ۶۴ بیتی یکتا که خود دستگاه رو در فضای آدرس IEEE EUI64 معرفی می‌کنه.
• DevNonce: یک شمارنده ۲ بایتی که از زمان روشن شدن اولیه دستگاه از صفر شروع میشه و با هر Join-request یکی بهش اضافه میشه. همین DevNonce جلوی حمله‌های تکراری (Replay Attack) رو می‌گیره.

 ✅ نکته مهم

روی همه این فیلدها یک MIC (Message Integrity Code) محاسبه میشه که این بار با استفاده از NwkKey ساخته میشه و به پیام Join-request اضافه میشه.

توجه: کلید NwkKey هیچ‌وقت ارسال نمیشه و پیام Join-request هم رمزگذاری نمیشه؛ به صورت متن ساده (Plain Text) ارسال میشه.

دستگاه می‌تونه این پیام رو با هر نرخ داده‌ای و از طریق یکی از کانال‌های مخصوص فعال‌سازی (join channels) ارسال کنه. مثلاً در اروپا دستگاه می‌تونه به‌صورت تصادفی یکی از فرکانس‌های 868.10 MHz، 868.30 MHz یا 868.50 MHz رو انتخاب کنه. پیام Join-request از طریق یک یا چند گیت‌وی به سرور شبکه می‌رسه.

در نهایت اگر درخواست توسط سرور پذیرفته نشه، هیچ پاسخی به دستگاه داده نمیشه؛ یعنی سکوت سرور یعنی رد شدن Join-request.

گام دوم در فرآیند Join (LoRaWAN 1.1)

وقتی سرور شبکه پیام Join-request رو دریافت می‌کنه، اون رو به سرور مربوطه یعنی Join Server فوروارد می‌کنه. این همون سروریه که مسئول بررسی درخواست‌های Join و مدیریت کلیدهای امنیتی هست.

گام سوم در فرآیند Join (LoRaWAN 1.1)

سرور Join پیام Join-request رو پردازش می‌کنه. اگر دستگاه مجاز به ورود به شبکه باشه، سرور Join چهار کلید جلسه تولید می‌کنه:

• AppSKey: کلید مخصوص داده‌های اپلیکیشن برای رمزگذاری و رمزگشایی بارهای اپلیکیشن
• FNwkSIntKey: کلید مربوط به اعتبارسنجی پیام‌ها (Forwarding Network Session Integrity Key)
• SNwkSIntKey: کلید مربوط به اعتبارسنجی پیام‌ها در سطح خدمت (Serving Network Session Integrity Key)
• NwkSEncKey: کلید رمزگذاری بارهای شبکه

این تفاوت بزرگ LoRaWAN 1.1 نسبت به نسخه 1.0.x هست؛ جایی که فقط دو کلید جلسه (AppSKey و NwkSKey) وجود داشتن. در نسخه 1.1 برای امنیت بیشتر، کلیدهای شبکه به سه بخش مجزا تقسیم شدن تا مسئولیت‌ها و کاربردهای امنیتی دقیق‌تر تفکیک بشن.

گام چهارم در فرآیند Join (LoRaWAN 1.1)

اگر در گام قبل سرور Join اجازه اتصال دستگاه رو تأیید کنه و کلیدها با موفقیت تولید بشن، سرور شبکه پیام Join-accept رو آماده می‌کنه. این پیام شامل فیلدهای زیره:

• JoinNonce: یک شمارنده اختصاصی برای هر دستگاه که توسط Join Server تولید میشه. دستگاه از این مقدار به همراه کلیدهای ریشه استفاده می‌کنه تا کلیدهای جلسه خودش (FNwkSIntKey، SNwkSIntKey، NwkSEncKey و AppSKey) رو بسازه.
• NetID: یک شناسه ۲۴ بیتی منحصربه‌فرد برای شبکه.
• DevAddr: یک آدرس ۳۲ بیتی که سرور شبکه به دستگاه میده تا داخل شبکه شناخته بشه.
• DLSettings: یک فیلد ۱ بایتی که تنظیمات مربوط به پیام‌های downlink رو شامل میشه.
• RxDelay: مقدار تأخیری که باید بین ارسال (TX) و دریافت (RX) رعایت بشه.
• CFList: یک لیست اختیاری از فرکانس‌های کانال شبکه که دستگاه می‌تونه بهشون وصل بشه. این فرکانس‌ها بسته به منطقه جغرافیایی فرق دارن.

برای اینکه امنیت تضمین بشه، روی تمام این فیلدها یک Message Integrity Code (MIC) محاسبه میشه. این MIC در LoRaWAN 1.0 با استفاده از NwkKey ساخته می‌شد، اما در LoRaWAN 1.1 با JSIntKey محاسبه میشه. MIC به پیام اضافه میشه تا تضمین بشه هیچ تغییری توی مسیر ایجاد نشده.

خود پیام Join-accept هم رمزگذاری میشه. سرور شبکه برای این کار از الگوریتم AES در حالت ECB استفاده می‌کنه (جالبه که برای رمزگذاری از عملیات Decrypt در AES-ECB استفاده میشه). اگر پیام Join-accept به‌دنبال یک Join-request ایجاد شده باشه، با NwkKey رمزگذاری میشه. ولی اگر پیام در پاسخ به یک Rejoin-request ساخته شده باشه، از JSEncKey استفاده میشه.

در نهایت، سرور شبکه پیام Join-accept رمزگذاری‌شده رو به‌عنوان یک پیام downlink معمولی به دستگاه می‌فرسته. دستگاه هم پس از دریافت، اون رو پردازش و کلیدهای جلسه خودش رو تولید می‌کنه.

گام پنجم در فرآیند Join (LoRaWAN 1.1)

وقتی فرآیند Join به پایان رسید و کلیدها ساخته شدن، وظیفه تقسیم این کلیدها بین اجزای مختلف شبکه بر عهده Join Server هست. در این مرحله:

• کلید AppSKey به Application Server ارسال میشه. این کلید فقط برای رمزگذاری و رمزگشایی داده‌های اپلیکیشن استفاده میشه و تضمین می‌کنه که داده‌های واقعی فقط توسط اپلیکیشن مقصد خونده بشن.
• سه کلید شبکه یعنی FNwkSIntKey، SNwkSIntKey و NwkSEncKey به Network Server داده میشن. این کلیدها مسئولیت‌های مختلفی دارن: از اعتبارسنجی پیام‌ها گرفته تا رمزگذاری بارهای شبکه.

با این تفکیک، امنیت در LoRaWAN 1.1 یک لایه جدی‌تر پیدا می‌کنه. اپراتور شبکه دیگه دسترسی مستقیم به داده‌های اپلیکیشن نداره، چون AppSKey فقط در اختیار سرور اپلیکیشن قرار می‌گیره. از اون طرف، Network Server هم با کلیدهای مخصوص خودش می‌تونه یکپارچگی و امنیت پیام‌ها رو تضمین کنه.

به این ترتیب، دستگاه به‌طور کامل فعال میشه و شبکه هم آماده برقراری ارتباط‌های امن و پایدار خواهد بود.

گام ششم در فرآیند Join (LoRaWAN 1.1)

وقتی دستگاه پیام Join-accept رو دریافت می‌کنه، اون رو با استفاده از الگوریتم AES (در حالت encrypt) رمزگشایی می‌کنه. بعد با کمک کلیدهای ریشه یعنی AppKey، NwkKey و مقدار JoinNonce، کلیدهای جلسه (Session Keys) خودش رو تولید می‌کنه.

نحوه تولید کلیدها بسته به نسخه LoRaWAN متفاوته:

• در LoRaWAN 1.0.x:
  • کلید AppSKey از NwkKey مشتق میشه.
  • سه کلید شبکه (FNwkSIntKey، SNwkSIntKey و NwkSEncKey) همگی از NwkKey ساخته میشن.
• در LoRaWAN 1.1:
  • کلید AppSKey از AppKey مشتق میشه.
  • سه کلید شبکه (FNwkSIntKey، SNwkSIntKey و NwkSEncKey) از NwkKey ساخته میشن.

به این ترتیب دستگاه حالا رسماً روی شبکه فعال شده و آماده تبادل داده‌های امنه.

بعد از فعال‌سازی، اطلاعات زیر داخل دستگاه ذخیره میشه:

• DevAddr: یک آدرس ۳۲ بیتی که توسط سرور شبکه داده شده تا دستگاه رو درون شبکه شناسایی کنه.
• FNwkSIntKey: کلید جلسه‌ای که برای محاسبه بخشی از MIC پیام‌های uplink استفاده میشه تا یکپارچگی داده‌ها تضمین بشه.
• SNwkSIntKey: کلید جلسه‌ای که برای محاسبه بخشی از MIC پیام‌های uplink و همچنین MIC همه پیام‌های downlink استفاده میشه.
• NwkSEncKey: کلید جلسه‌ای که برای رمزگذاری و رمزگشایی بارهای MAC داخل پیام‌های uplink و downlink به کار میره تا محرمانگی داده‌ها حفظ بشه.
• AppSKey: کلیدی که بین دستگاه و سرور اپلیکیشن مشترکه و برای رمزگذاری و رمزگشایی داده‌های اپلیکیشن در پیام‌ها استفاده میشه.

به این شکل، بعد از گام ششم همه‌چیز آماده است: دستگاه هم آدرس داره، هم کلیدهای امنیتی کامل، و هم یک کانال امن برای تبادل داده با شبکه و اپلیکیشن.