ملاحظات موفر إنترنت الأشياء. التنشيط والأمن في LoraWAN

مرحبا عزيزي انترنت عشاق الاشياء. تلاحظ استمرار مزود إنترنت الأشياء.

الجزء الأول > || > الجزء الثاني > || > الجزء الثالث > || > الجزء الرابع

حان الوقت اليوم للحديث عن الأمن في LoRaWAN. هناك العديد من الشائعات والأساطير. سنحاول معرفة كيف يعمل وما هي المخاطر.

من أجل الانتقال إلى موضوع الأمان ، سيكون عليك تقديم مقدمة صغيرة والتحدث عن التهيئة الأولية لوحدة الراديو على الشبكة. هذه العملية في LoRaWAN تسمى التنشيط.

للإيجاز ، سأدرج أدناه المصطلحات التي نحتاجها. إذا كنت مرتبكًا قليلاً - يمكنك العودة إلى هنا والتحقق. ربما يجب عليك العودة ، لأنه اختصارات العديد من المصطلحات متشابهة للغاية. بالإضافة إلى ذلك ، سأقدم في هذا الوصف قياسات حتى تفهم تقريبًا ما يمكن مقارنة هذا المصطلح أو ذلك المصطلح. ليس من الممكن دائمًا تحديد المقارنات الدقيقة ، لذا يرجى عدم الحكم بدقة على هذا العمود.

لذلك ، يمكن إجراء التنشيط في LoRaWAN عن طريق الجو (OTAA) ، أو عن طريق الضبط المسبق (ABP).

OTAA (التنشيط عبر الهواء)

في حالة التنشيط عن طريق الجو ، يجب تعيين ثلاث معلمات على وحدة الراديو الخاصة بنا. معرفه الفريد (DevEUI) ومعرف الخادم (AppEUI) ومفتاح الخادم (AppKey).

على جانب الخادم ، يجب أيضًا تسجيل معرف وحدة الراديو ومعرف الخادم والمفتاح. على سبيل المثال يجب أن يعرف الخادم في البداية الجهاز الذي سيحاول الانضمام إليه. إذا كنا نعرف المعرفات ومفاتيح الخادم ، ولكن DevEUI لدينا غير مسجل في قاعدة بياناته ، فسوف يفشل الاتصال.

عند التشغيل المبدئي ، يرسل الراديو حزمة join_request على الهواء في أحد ترددات الصلة الثلاثة المحددة مسبقًا. مع هذه الحزمة ، يسأل عما إذا كانت هناك شبكة قريبة من شأنها "التعرف عليه". فيما يلي تكوين حزمة join_request. كما ترون ، فإنه يحتوي على DevEUI و AppEUI ، بالإضافة إلى DevNonce.

DevNonce هو متغير عشوائي. يقوم الخادم بتخزينه في الذاكرة لبعض الوقت ، وإذا وصل join_request بنفس DevNonce مثل أحد التطبيقات السابقة ، فإن الخادم سيتجاهل هذا الطلب. هذا للحماية من هجوم متكرر عندما يمكن للمهاجم كتابة طلب تنشيط ثم تكراره من جهازه. بالمناسبة ، لا يمكن لجميع معايير إنترنت الأشياء أن تتباهى بالحماية ضد هذا الهجوم.

لا يتم استخدام AppKey بشكل مباشر في هذه الرسالة ، ولكن من خلاله يتم اعتبار المجموع الاختباري لـ MIC في نهاية الإطار.
سنحتاج إلى هذا المفتاح أكثر قليلاً ، في رسالة الاستجابة من خادم join_accept.

يتم نقل Join_request بدون تشفير.

سيتم استقبال Join_accept إذا كان الخادم يعرف AppEUI و DevEUI ، بالإضافة إلى عدم وجود تطابق في حقل DevNonce ولا توجد مشاكل في MIC. وإلا ، فلن تكون هناك إجابة. إذا تم اجتياز جميع عمليات التحقق ، فسيقوم الخادم بإنشاء رسالة استجابة join_accept. يظهر تكوينه في الصورة أدناه.

في الواقع ، يتم إنشاء مفتاحي جلسة - خادم الشبكة (NwkSKey) وخادم التطبيق (AppSKey). يتم تشفير هذه المفاتيح إلى جانب معلومات أخرى بواسطة AppKey وإرسالها إلى وحدة الراديو. علاوة على ذلك ، تحدث جميع الرسائل مع التشفير المزدوج مع مفاتيح الجلسة (باستثناء الحزم التي تحتوي على أوامر MAC ، لا يتم تشفيرها باستخدام مفتاح خادم التطبيق). لا يشارك NwkSKey في تشفير الحزم فقط مع البيانات (بدون أوامر) ، ولكن يتم أخذ المجموع الاختباري من خلاله.
NwkSkey و AppSKey فريدان لكل وحدة راديو فردية.

يتم استخدام مفتاحين لحماية المعلومات الإضافية. في كل مرة تصل حزمة من وحدة الراديو إلى نظامنا ، سيتم تشفيرها جزئيًا لخادم الشبكة وجزئيًا لخادم التطبيق. على سبيل المثال سيكون خادم الشبكة قادرًا على فك تشفير تلك الرسائل الموجهة إليه فقط (رسائل الخدمة المختلفة). سيرى خادم التطبيق فقط المكون المفيد للحزم (في الواقع يتم إعادة توجيه البيانات). يعد ذلك ضروريًا لأن خادم الشبكة مع احتمال بنسبة 99 بالمائة سيكون في الموفر. ولكن قد يتم استضافة خادم التطبيق من قبل العميل. التشفير المزدوج يجعل من الصعب على الموفر معرفة محتويات الحزمة.

بالإضافة إلى المفتاحين ، هناك شيء آخر مهم للانضمام إلى قبول OTAA - قائمة الترددات الموسعة (CFList). دعني أذكرك بأن وحدة الراديو في البداية لا تعرف سوى ثلاث ترددات يمكنها العمل فيها. بعد التنشيط ، يتم تسجيل ترددات إضافية للتواصل.

يعد هذا مناسبًا جدًا إذا لم يكن معروفًا بالضبط في أي شبكة سيعمل الجهاز. يمكننا أن نتفق على أنه في جميع الشبكات ، تتزامن 3 ترددات (+ RX2) دائمًا ، والخمس المتبقية المتبقية وفقًا لتقدير المزود.

أيضًا ، بالنسبة للمستقبل ، يمكن استخدام العمل مع عدد كبير من الأجهزة CFList للتجميع

هذا عندما تقوم بتقسيم الشبكة إلى مجموعات وداخل المجموعات هناك تخطيط للترددات. لنفترض أن وحدة الراديو لدينا تعرف الترددات الثلاثة F1 و F2 و F3. يتم تنشيطه في أحد الترددات وإذا كان في المجموعة 1 ، فإنه يتلقى جدول تردد إضافي في شكل F4-1 و F5-1 و F6-1. بالنسبة للمجموعة 2 ، سيحصل على F4-2 و F5-2 و F6-2 مختلفة تمامًا. في الوقت نفسه ، يمكننا تكوين جميع وحدات الراديو بنفس الطريقة ولا نفكر حقًا في أي وحدة ستقع في أي مجموعة. وفي التجمعات المجاورة ، سينخفض ​​احتمال الاصطدامات بشكل حاد.

ABP (التنشيط بالتخصيص)

إجراء مبسط عندما يتم توصيل مفاتيح الجلسات مباشرة في وحدة الراديو ويتم تسجيلها مبدئيًا من جانب الخادم. ملائمة لأنك لست بحاجة إلى التنشيط ، فإن وحدة الراديو جاهزة للاستخدام على الفور. لا شيء أكثر ملاءمة ، لأنه السلامة في هذه الحالة حتى. بالإضافة إلى ذلك ، لا يمكنك سحب الترددات من الخادم. لم يسبق لي أن رأيت أي حالات للاستخدام الحقيقي. لن نفكر في ذلك ، وكل ما يلي يتعلق بـ OTAA.

وماذا عن الأمن؟

لذا ، في الأساس ، لدينا عبء التشفير الرئيسي على مفاتيح الجلسة لخادم الشبكة وخادم التطبيق.

اعتبرهم أكثر دقة.

الشكوى الرئيسية من منتقدي معيار LoRaWAN هو أنه عندما يتم تنشيط الجهاز على الشبكة ، لدينا مفتاحان ، والذي يمكن أن يظل دون تغيير لأشهر. بتعبير أدق ، قد لا تتغير لسنوات حتى يتم إعادة تنشيط الجهاز. في الظروف العادية ، قمنا بتنشيط ونسيان وحدة الراديو ، لذا فإن الحياة الرئيسية التي تتراوح من ثلاث إلى أربع سنوات هي فرصة واقعية للغاية. في الواقع ، من التثبيت إلى ترك البطارية عند الصفر.
ما مدى مصداقية مفاتيحنا؟

تقول المواصفات أنها تتوافق مع RFC4493 الغامض.
ما هذا هذه خوارزمية تشفير معروفة باسم AES-CMAC.

دعونا لا نزحف إلى براري التشفير ونقتصر على فهم مشترك للصورة. يتم تقديمه في الشكل أدناه.

مبدأ AES-CMAC هو تقريبًا ما يلي: تنقسم الرسالة المشفرة إلى كتل 128 بت. يتم تشفير كل كتلة على حدة باستخدام مفتاح AES. علاوة على ذلك ، عند تشفير الكتلة الثانية ، بالإضافة إلى المفتاح ، يتم استخدام نتيجة التشفير الأولى. وعند تشفير الثالث - نتيجة الثانية و (بشكل غير مباشر) الأول. مثل هذه السلسلة من التعقيدات.

ما مدى مصداقية هذا المبدأ؟

موثوق للغاية. ظهرت الخوارزمية قبل أكثر من عشر سنوات. منذ ذلك الحين ، تعرض للهجوم من قبل العديد من الهجمات المختلفة ، وأخيرا ، من الناحية النظرية ، أثبتوا أنه يمكن اختراقه ، والمشكلة هي أن عينة كبيرة من الحزم ، عدة آلاف ، ستكون هناك حاجة لكسرها. ثم هناك فرصة لفهم ما هو داخل الكتل المشفرة.

هل يمكن للمهاجم بالمعرفة الضرورية الحصول على هذه العينة إذا كنا نتحدث عن اعتراض حزم LoRaWAN؟ دعونا نقدر. دع الحزم تذهب مرة كل ساعة. في الشهر ، سيتم نقل 720 حزمة من وحدة الراديو. لا يكفي.

للتهديد الحقيقي ، نحن بحاجة إلى مريض صبور للغاية سيكتب حزم لأشهر. وليست حقيقة أنه لا يزال بإمكانه كسر الخوارزمية والحصول على المفاتيح الثمينة. لا تنس أنه يجب إظهار مثل هذا الصبر فيما يتعلق بكل وحدة راديو على حدة. وتذكر أن إرسال الحزم مرة واحدة في الساعة غالبًا ما يكون. من الناحية العملية ، تكون الفترات الزمنية أطول بكثير - ست ساعات ، أو حتى يوم واحد.

ولكن حتى هذه الفرصة الشبحية مغلقة الآن بعد إصدار المواصفات 1.1 ، حيث يتم تنفيذ أوامر إعادة التنشيط والانضمام إلى خادم. لنتحدث عن هذه المواصفات بطريقة أو بأخرى. في الوقت الحالي ، أتذكر فكرتي من المقالة السابقة: عندما يكون المعيار مفتوحًا ولديه مجتمع ، تكون جميع ثقوبه مرئية. أثناء الترقية ، يعرف المطورون بالضبط ما يجب أن ينظروا إليه أولاً.

نتيجة لذلك ، نكتشف أن التهديد الأمني ​​مجرد وهم. في مكان ما من النظرية العميقة ، يمكن القيام بالقرصنة ، ولكن في الممارسة العملية ليست واقعية. الآن اضرب في قيمة المعلومات الواردة. هل سيبدأ المهاجم في كتابة حزم لأشهر لاكتشاف العداد؟ من غير المحتمل.

تلبي LoRaWAN نسبة السعر إلى الأداء المعقولة. نحن نفهم أنه يمكن تعزيز الحماية. ولكن هذه هي قوة الحوسبة للنهاية ، وهذا حمل إضافي على البطارية ، فمن الممكن زيادة حجم الحزم أو تقليل الحمولة.

بالنسبة لي ، إنها أكثر من مجرد مهمة للقياس عن بعد.

في التعليقات ، سأكون سعيدًا لسماع خصومي ومؤيدي. تذكر أن موضوع الأمان يتطلب دائمًا مناقشة ويجب ألا يرتكز أبدًا على رأي شخص واحد.