يُعد الوعي بالمجال البحري (MDA) مجالًا استراتيجيًا يسعى إلى تزويد الدولة الساحلية بمراقبة فعالة لمواردها البحرية ومنطقتها الاقتصادية الخالصة (EEZ). ويستفيد نظام المراقبة البحرية (MMS) من المراقبة النشطة للأنشطة العسكرية وغير العسكرية في البحر باستخدام أجهزة استشعار مثل الرادارات والأجهزة الكهروبصرية وأنظمة التعريف الآلية (AIS) وإنترنت الأشياء وغيرها. غير أن نشر نظام مراقبة بحرية على مستوى الدولة يفرض تحديات كبيرة على قابلية التوسع والأمن السيبراني لهذا النظام غير المتجانس.
ولمواجهة هذه التحديات، تستكشف هذه الورقة استخدام البلوك تشين لتعزيز الأمن السيبراني لنظام المراقبة البحرية وضمان سلامة بيانات الملاحة ذات الصلة وأصالتها وتوافرها. ونقترح نموذجًا أوليًا مبنيًا على حل بلوك تشين مُصرَّح به باستخدام HyperLedger Fabric — وهي منصة مفتوحة المصدر قوية ووحداتية وفعالة. ونقيّم أداءها عبر تجربة عملية يستقبل فيها النموذج بيانات الاستشعار من مستقبل AIS منخفض التكلفة قائم على الراديو المعرف برمجيًا (SDR) ومبني بـRaspberry Pi. ولتقليل تآكل قابلية التوسع، طورنا عميل بلوك تشين مُحاوى (dockerized) سهل النشر على نطاق واسع، وحددنا التهيئة العتادية المثلى للعميل لخفض تكاليف التنفيذ والصيانة. وتقدم النتائج تحليلًا كميًا لعبء تقنية البلوك تشين وأثره على جودة الخدمة (QoS)، مظهرة جدوى الحل وفعاليته في نظام مراقبة بحرية يستخدم بيانات AIS.
مع الزيادة الأسية للهجمات السيبرانية وآثارها [1–4]، تسعى الدول للدفاع عن مجالاتها السيبرانية — ويسعى المجتمع البحري لتأمين أنظمة رقمية يتسع سطح هجومها مع التقنيات الجديدة. فالسفن تغدو أنظمة سيبرانية–فيزيائية معقدة تدمج مستشعرات الملاحة وأنظمة المعلومات والتحكم. وتغذي التقنيات الرقمية باطراد أنظمة المراقبة البحرية (MMSs) [5] التي تجمع بيانات الرحلات المرسلة عبر أنظمة التعريف الآلية للسفن (AISs). لكنها تعرض القطاع لتهديدات المجال السيبراني النمطية: فنشرت المنظمة البحرية الدولية إرشادات إدارة مخاطر الأمن السيبراني البحري [6]، وأطلقت الولايات المتحدة خطتها الوطنية للأمن السيبراني البحري [7]، وارتفعت الهجمات السيبرانية البحرية 900% في ثلاث سنوات [8]، مما يبين الحاجة لأدوات تخفف الثغرات السيبرانية–الإلكترونية [9].
ويمكن للأنظمة القائمة على البلوك تشين تعزيز أمن البيانات عبر اللامركزية والتشفير المتطور. فبعد أن سادت في القطاع المالي عقدًا [10]، تنتشر البلوك تشين الآن في القطاعات العسكرية وغيرها لتأمين الأنظمة الحرجة. ومع نمو إنترنت الأشياء في الشحن الذاتي والملاحة والمراقبة [11]، يغدو نظام اتصال آمن وموثوق حرجًا — وتدرج خطة تنفيذ استراتيجية الملاحة الإلكترونية [12] تحسين الموثوقية وسلامة البيانات بين احتياجات مستخدمي السفن وأولوياتهم.
تستهدف هذه الورقة نظام مراقبة بحرية وطني النطاق أجهزة استشعاره معزولة وغالبًا في بيئات خطرة: فقد يعبث المهاجمون بالمستشعرات المادية أو قنوات التردد الراديوي، مقوضين السلامة والأصالة [11]، أو تعرض هجمات بأسلوب SolarWinds [1] توافر قاعدة بيانات النظام للخطر. ونقترح نظام مراقبة بحرية قائمًا على البلوك تشين يؤمن سلامة بيانات استشعار حركة السفن وأصالتها وتوافرها، باستخدام خوارزمية توافق Raft لتحمل الأعطال مع نفاذ مُصرَّح به عبر التشفير. ونقيّم جودة الخدمة في زمن الاستجابة وحجم البيانات، وجدوى وأداء عملاء البلوك تشين على أجهزة إنترنت أشياء محدودة الموارد ومنخفضة التكلفة — مع تحوية عميل AIS على Raspberry Pi وتغيير الملامح العتادية. والمساهمات هي: نموذج أولي عامل لنظام مراقبة بحرية ببلوك تشين مُصرَّح به على Fabric مع Raft يستقبل بيانات AIS ويخزنها بأمان؛ ودمجه مع مستقبل AIS منخفض التكلفة من البحرية البرازيلية في بيئة حقيقية؛ وتقييمه عبر تهيئات عتادية للعميل؛ وتحديد عبء البلوك تشين كميًا مقابل مستويات جودة الخدمة المرغوبة.
البلوك تشين تقنية مُحدثة للثقة بين أطراف لا يثق بعضها ببعض [13–15]: دفتر أستاذ لامركزي موزع يُلحق به فقط [16] عبر شبكة ند-لند، بكتل مربوطة تشفيريًا ومنسوخة، وعقود ذكية [16]، وبروتوكولات توافق تضمن السلامة والاتساق [14]. وينقسم التوافق إلى قائم على الإثبات (PoW وPoS وPoET — شبيه باليانصيب، بلا إذن [15]) وقائم على التصويت (متحمل للأخطاء البيزنطية/التعطلية — نصاب أقران معروفين، أي بلوك تشين مُصرَّح بها [14]): فيجمع الأول مشاركين أكثر بإنتاجية ضعيفة، بينما يجمع الثاني إنتاجية أعلى بكثير — حتى مئة ضعف [14،17]. ومن المنصات Bitcoin [13] وEthereum بعقود Solidity الذكية [19] (كلتاهما بلا إذن)، وHyperledger Fabric [18] — الوحداتي والمُصرَّح به عادة، مع توافق Raft الأصيل [14–16] المتحمل لتعطل الأعطال والقائم على القائد منذ 2018، والذي يتحمل الفشل ما دام 50% زائد واحد من النصاب يعمل.
وفي إنترنت الأشياء وشبكات الاستشعار، بنى Al-Sahan وآخرون [20] نظام مراقبة ببلوك تشين مُصرَّح بها على Fabric يدمج أصحاب مصلحة غير متجانسين مع تعلم آلي للتعرف على الوجوه؛ وقارن Melo وآخرون [21] بين Ethereum وFabric لمراقبة البنى الحرجة، متفوقةً Fabric قليلًا في الإنتاجية والوحداتية والأدوات؛ واقترح Bandara وآخرون [22] بلوك تشين خفيفة لإنترنت الأشياء بتوافق Kafka وتجزئة؛ واستخدم Gil وآخرون [23] حاويات Docker لتيسير إعداد العميل وقابلية التوسع؛ وحلل Honar وآخرون [24] أداء Fabric على أجهزة إنترنت أشياء مقيدة الموارد، محسّنين الإنتاجية وزمن الاستجابة واستهلاك الموارد مع تحقيق المتطلبات الأمنية.
وفي الأمن السيبراني البحري، يقيّم المرجع [26] المخاطر السيبرانية في أنظمة ملاحة السفن وفق إرشادات IMO [6]؛ ويفحص المرجع [27] أنظمة الملاحة المتكاملة (ECDIS والرادار/ARPA وAIS) بماسح الثغرات؛ ويستخلص Kavallieratos وآخرون [28] متطلبات أمن ECDIS/GMDSS/AIS عبر Secure Tropos [29] (منع فقد AIS وحماية بيانات الرحلات وتوثيق الفاعلين)؛ ويوثق Androjna وآخرون [30] هجوم انتحال AIS قرب إلبا بآلاف التدفقات المزيفة؛ ويقترح Goudossis وآخرون [31] وKessler [32] تشفيرًا متماثلًا وقائمًا على الهوية وAIS محميًا بالمفتاح العام (pAIS). ويركز الجميع على أمن السفن أو الأمن بين السفن — بينما يبقى تكامل أنظمة المراقبة البحرية واسعة النطاق قليل الاستكشاف. وفي بلوك تشين للقطاع البحري، أمّن Rahimi وآخرون [11] استشعار العوامات والطائرات المسيرة عبر Ethereum بعبء 13–18% في التأخير و12–16% في الإنتاجية؛ وحقق Zhang وآخرون [33] تحسنًا أمنيًا 8% وسرعة معاملات 6% في أنظمة النقل البحري؛ وخفض Jiang وآخرون [34] الطاقة 78% بإثبات حصة خفيف لإنترنت الأشياء الطرفية. وفي حدود علمنا، لا يوجد عمل ينفذ بلوك تشين مُصرَّحًا بها بـFabric في أنظمة المراقبة البحرية — وهي الفجوة التي تملؤها هذه الورقة، بتقييم في سيناريو حقيقي بعملاء منخفضي التكلفة.
يدرس الوعي بالمجال البحري (MDA) [35–37] الأحداث والظروف العسكرية وغير العسكرية في البيئة البحرية من البيانات المتاحة، وأساسًا المستشعرات: فتجنب التصادم عبر كشف العوائق والتنبؤ بالمواجهات القريبة مفتاح الشحن الآمن. ويجب على السلطات مراقبة مجالها ومنطقتها الاقتصادية ضد الصيد غير المشروع والاتجار غير المشروع والتلوث والقرصنة. وAIS هو أداة المراقبة الأولى: فمحطات AIS في مواقع ساحلية استراتيجية تجمع MMSI والاسم والموضع والسرعة والاتجاه من السفن ضمن ~40 ميلًا بحريًا، مغذية عروضًا منظمة والتنبؤ بالسلوك بتعلم الآلة؛ وتكملها الرادارات والكاميرات. وتفرض اتفاقية SOLAS (IMO) أجهزة إرسال واستقبال AIS على السفن فوق 300 طن إجمالي عالميًا. وقد تقبع أجهزة الاستشعار على العوامات والطائرات المسيرة بقدرة وطاقة محدودتين، متواصلة عبر شبكة WMAN معشقة كمرحلات [38] إلى مركز دمج بيانات لكل منطقة بحرية (ND) يجمع البيانات ويحيلها إلى السلطة البحرية لتخزينها في قاعدة مركزية أو موزعة زائدة.
وتواجه المستشعرات في الأماكن النائية العبث: فتهديدات GNSS وECDIS وAIS للسلامة موثقة جيدًا [30]، مما يحفز الإشارات المشفرة والأمن السيبراني المتين. ويغطي نموذج هجومنا أربعة سيناريوهات بثغرات معروفة (مثل PostgreSQL CVE-2019-9193 [39]) وتقنيات سلاسل إمداد بأسلوب SolarWinds [1]: (1) هجوم التوافر — اختراق شبكة السلطة البحرية عبر باب خلفي في سلسلة الإمداد واستغلال عيوب قاعدة البيانات، مع العجز عن ضرب كل المناطق؛ (2) هجوم السلامة — استخدام بيانات اعتماد داخلية مُكرَهة لتعديل البيانات المخزنة سرًا؛ (3) هجوم التواطؤ — خوادم مخترقة في عدة مناطق تتعاون لتدهور التوجيه والسلامة والتوافر [40] دون إفساد كل الخوادم؛ (4) اختطاف الطائرات المسيرة — التنصت وانتحال روابط التردد الراديوي غير الموثقة بين الطائرة والمشغل ضمن التغطية.
ويعمل نظام المراقبة البحرية القائم على البلوك تشين على Fabric لسلامة بيانات الاستشعار وأصالتها وتوافرها، مع عملاء بلوك تشين مضغوطين بـDocker وحاويات محدودة المعالج/الذاكرة لكفاءة الموارد. وتعمل العوامات والطائرات المسيرة كعملاء بلوك تشين ببيانات اعتماد تشفيرية تديرها MSP؛ ويحمل كل منها مستقبل AIS منخفض التكلفة من البحرية البرازيلية (هوائي سوطي VHF ودونغل إزالة تضمين SDR وRaspberry Pi 3). ويرسل العملاء سلاسل NMEA كمعاملات عبر Python Fabric SDK [41،42] إلى الأقران المصدقة في المنطقة المسؤولة: فيتحقق المصدقون من الأصالة والسلامة، وينفذون العقد الذكي (استعلام أو أمر أو معالجة قبل التخزين)، ويوقعون بالمفاتيح الخاصة، ويعيدون التصديقات؛ ويجمع العميل عدد التصديقات الذي تفرضه السياسة — القابل للضبط حسب المستوى الأمني بكلفة حوسبة التوقيع غير المتماثل — ويقدمها لخدمة الترتيب Raft التي ترتب الكتل وتبثها ليتثبت منها الأقران الملتزمون ويلحقونها بلا رجعة (الأشكال 1–3). وتُحجز المعاملات المتضاربة للتدقيق؛ وتصبح بيانات الدفتر غير قابلة للتغيير.
ويُظهر تحليل الأمن (الشكل 4): أن النظام المركزي معرض في السيناريوهات الأربعة (نقطة فشل وحيدة؛ قاعدة قابلة للتعديل؛ لا تحمل أعطال؛ روابط طائرات غير موثقة). وأن نظام قاعدة البيانات اللامركزية ينجو في سيناريو التوافر فقط. بينما يقاوم النظام القائم على البلوك تشين الأربعة: فالدفتر الموزع يهزم نقطة الفشل الوحيدة؛ وثبات السجل يهزم التعديل الصامت؛ وتحمل أعطال Raft يهزم التواطؤ دون 1/3–1/2 العقد؛ والتشفير غير المتماثل مع إدارة مفاتيح MSP يؤمن اتصالات الطائرات–المشغل. ويُعمم التحليل على أي شبكة استشعار لإنترنت الأشياء على قواعد تقليدية.
تتطلب تغطية المساحات الواسعة إطلاق أجهزة عديدة في مواقع مميزة — لذا تَلزم منهجية لاكتشاف الحد الأدنى من الموارد لتطبيق عميل البلوك تشين، تجنبًا لكلفة شراء أجهزة كثيرة واختبارها وإعادة تنفيذ التطبيق بلغات إنترنت أشياء متعددة. والحل: بناء صورة Docker بجميع اعتماديات العميل مُجمّعة مسبقًا، ثم إنشاء حاويات بحدود متفاوتة للمعالج/الذاكرة — إذ يعالج نواة المضيف عمليات الحاويات عبر النطاقات ومجموعات التحكم، فيمكن تقييد استهلاك كل حاوية (غير محدود افتراضيًا؛ والتقييد عبر مجدول CFS في Linux [43]). وتؤكد أعمال سابقة الحاويات لمحاكاة أساطيل إنترنت الأشياء والمركبات المتصلة [44–46]، بما فيها مراجعات النمذجة والمحاكاة كخدمة [46]، لكنها نادرًا ما تفصل تهيئة بارامترات الأجهزة — وهي الفجوة التي يملؤها نهج Docker-compose لدينا.
ويُحضَّر التصوير بخطوتين: (1) صورة Docker من مستودع Python على Docker Hub (Python 3.7 على Debian Buster لمعمارية ARM، بما يوافق Raspberry Pi وخبرة Python SDK لـFabric) بجميع اعتماديات العميل مُجمّعة مسبقًا؛ (2) تجميع HyperLedger Fabric SDK واعتمادياته — منتجة بيئة عاملة سريعة الإقلاع وقابلة للتوسع، منشورة على Docker Hub [47] مع README ومثال Docker-compose.yaml (حدود الموارد تحت مفتاح deploy) ومثال Dockerfile. ثم تجوب التجارب حدود المعالج والذاكرة لإيجاد التهيئة الدنيا القابلة للعمل ورصد حيث تتوقف الموارد الإضافية عن الجدوى — مع إعادة إنشاء الحاويات لكل إعداد بمجرد تحرير Docker-compose.yaml.
تربط البيئة (الشكل 5) عميل البلوك تشين (Raspberry Pi، يمينًا) بخادم Linux مُجَهَّز افتراضيًا (يسارًا، بمشرف VirtualBox [48] على macOS) مع عزل كل كيان بلوك تشين في حاويته Docker؛ وشيفرة النموذج الأولي عامة على GitHub [49]. ويحاكي الخادم عقدة بلوك تشين لمنطقة بحرية (Intel Core i5 بسرعة 1.8 غيغاهرتز وذاكرة 2048 ميغابايت)؛ ويستقبل عميل Raspberry Pi 3 (Cortex-A53 رباعي 1.4 غيغاهرتز وذاكرة 1024 ميغابايت) بيانات الاستشعار NMEA عبر المنافذ 7050–7054. والتقط هوائي VHF السوطي قرب خليج غوانابارا (ريو دي جانيرو) حركة AIS بحرية حقيقية، أزال تضمينها دونغل SDR إلى مدخلات نصية؛ ولمحاكاة نظام مراقبة كبير، أُرسلت 1500 مدخلة AIS تمثل 100 عقدة × 15 مدخلة في الدقيقة.
وقيس عبء البلوك تشين مقابل SSH (بتشفير متماثل وغير متماثل معًا). فإرسال 1500 مدخلة عبر SSH استهلك 8% من المعالج (±5%) مع ~7% للنظام و~156 ميغابايت ذاكرة (الشكل 6a)؛ وعبر البلوك تشين 17% (±8%) مع ~6% للنظام و~180 ميغابايت (الشكل 6b) — أي عبء 9% معالج و14.7% ذاكرة — بينما كان إرسال البلوك تشين أسرع 60% (~60 ث مقابل ~150 ث). واستخدم العميل 17.6% فقط من ذاكرته و16.9% من معالجه: وهو حرج، إذ تحمل عقد الاستشعار على العوامات والطائرات حمولات خفيفة، وتواجه طقسًا قاسيًا وعبثًا، وتفتقر لموارد الخوادم. وفي جانب الخادم (الشكل 7)، استهلك العقد الذكي 3% معالج / 4.3 ميغابايت فقط (منطق تحقق AIS فحسب)، والمصدّق 11.7% معالج / 102 ميغابايت (التوقيع غير المتماثل)؛ واستهلكت كل الحاويات 224.2 ميغابايت (11% من 2048) و34.4% من المعالج — محققة مستويات جودة خدمة جيدة، مع نمو الاستهلاك بحجم البلوك تشين بينما تتوسع قدرة الخادم أسهل من عقد الاستشعار.
ثم قيس العملاء المُحاوَوْن عبر حدود عتادية لإيجاد النقطة المثلى للموارد (كل نسب المعالج تشير لنواة واحدة من Raspberry Pi): 200 مدخلة AIS × 30 تكرارًا لكل إعداد. ويحتاج العميل 18 ميغابايت ذاكرة و10% معالج على الأقل؛ وفوق 30 ميغابايت بالكاد يتحسن زمن التنفيذ، فلم تُستكشف ذواكر أعلى. ويُظهر اختبار حدود 10/30/50/70/90% معالج مقابل 18/20/25/30 ميغابايت (الشكل 8) انخفاضًا شبه أسي لزمن الإرسال من 10% إلى 70% معالج، ثم ارتفاعًا طفيفًا عند 90% من تنافس Docker مع مكالمات شبكة النظام — فـ70% من نواة واحدة هو الإعداد الأمثل حوسبيًا. وعند 18–20 ميغابايت يرتفع المعالج المستخدم من تخصيص 50% إلى 70%، بينما عند 25–30 ميغابايت ينخفض باطراد (الشكل 9a)؛ وتُظهر خريطة الأداء (الشكل 9b) أن 70% معالج مع 25 أو 30 ميغابايت متساويا السرعة، لكن 30 ميغابايت تستهلك معالجًا أكثر — فـ25 ميغابايت هي حجم الذاكرة الأمثل كفاءة، مخفضة كلفة العتاد والطاقة والنشر/الصيانة على النطاق الوطني. ونؤكد أن المتانة تنبع أساسًا من عدد الأقران والتكرار الاحتياطي لا من قوة العتاد الفردي.
معظم الأنظمة البحرية العاملة — بما فيها الاتصالات والملاحة والمراقبة — ضعيفة النضج سيبرانيًا. وللحد من الثغرات، قدمت هذه الورقة نموذج نظام مراقبة بحرية قائمًا على البلوك تشين يعزز الأمن ويضمن سلامة بيانات الاستشعار وأصالتها وتوافرها. وطورنا بنجاح نموذجًا أوليًا ببلوك تشين مُصرَّح بها على منصة HyperLedger Fabric، وأتحناه علنًا ليتمكن باحثون آخرون من تكرار التجربة؛ وأظهر تحليل الأمن كيف تخفف البلوك تشين ثغرات أنظمة المراقبة البحرية.
ودمجنا النموذج الأولي مع مستقبل AIS منخفض التكلفة من تطوير البحرية البرازيلية وأرسلنا 1500 مدخلة AIS حقيقية لمحاكاة تشغيل النظام في بيئة حقيقية. ورغم زيادة استهلاك المعالج والذاكرة، يبقى العبء عند مستوى جودة خدمة مقبول تبرره مكاسب أمن البيانات. ويتيح عميل البلوك تشين المُحاوى استهلاكًا ذكيًا للموارد على عقد الاستشعار مع تيسير مشكلات قابلية توسع شبكات إنترنت الأشياء واسعة النطاق؛ وحددت التجارب التهيئة المثلى للعميل — 70% من نواة Raspberry Pi واحدة مع 25 ميغابايت ذاكرة — مخفضة تكاليف النشر والصيانة بكفاءة موارد. وإضافة إلى الأمن السيبراني لأنظمة المراقبة البحرية، يمتد الحل والشيفرة ومنهجية التهيئة العتادية إلى أنظمة استشعار بحرية واسعة أخرى مثل المراقبة البيئية وشبكات الاستشعار اللاسلكية وتقنيات إنترنت الأشياء، بفوائد في التكلفة وكفاءة الطاقة.
وفي العمل المستقبلي، نخطط لتوسيع النموذج الأولي إلى نظام مراقبة بحرية كامل قادر على مراقبة ساحل دولة بأكملها — إذ دمجنا حتى الآن AIS فقط، ولا يزال دمج أنظمة الاستشعار غير المتجانسة مطلوبًا. ومن الاتجاهات الأخرى دمج لامركزية البلوك تشين مع تحليل البيانات واتخاذ القرار بالذكاء الاصطناعي: نظام مراقبة بحرية يتطور إلى نظام قيادة وسيطرة يساعد اتخاذ القرار البحري، مع عقود ذكية على السلسلة تنفذ خوارزميات ذكاء اصطناعي لمعالجة قوية ورؤى تشغيلية سريعة ودقيقة تحت متطلبات أمنية حرجة.
Maritime Domain Awareness (MDA) is a strategic field of study that seeks to provide a coastal country with effective monitoring of its maritime resources and its Exclusive Economic Zone (EEZ). A Maritime Monitoring System (MMS) leverages active surveillance of military and non-military activities at sea using sensing devices such as radars, optronics, Automatic Identification Systems (AISs) and IoT, among others. Deploying a nation-scale MMS, however, imposes great challenges for scalability and cybersecurity of this heterogeneous system.
To address these challenges, this work explores blockchain to leverage MMS cybersecurity and ensure the integrity, authenticity and availability of relevant navigation data. We propose a prototype built on a permissioned blockchain solution using HyperLedger Fabric — a robust, modular and efficient open-source platform. We evaluate its performance through a practical experiment in which the prototype receives sensing data from a Software-Defined-Radio (SDR)-based low-cost AIS receiver built with a Raspberry Pi. To reduce scalability attrition, we developed a dockerized blockchain client easily deployed at large scale, and determined the optimal client hardware configuration to reduce implementation and maintenance costs. The results provide a quantitative analysis of the blockchain technology overhead and its impact on Quality of Service (QoS), demonstrating the feasibility and effectiveness of the solution for an MMS using AIS data.
With the exponential increase in cyberattacks and their impacts [1–4], nations seek to defend their cyber domains — and the maritime community pursues ways to secure digital systems whose attack surface grows with new technologies. Ships are becoming complex cyber–physical systems integrating navigation sensors, information and control systems. Digital technologies increasingly feed Maritime Monitoring Systems (MMSs) [5] collecting voyage data transmitted through ships' Automatic Identification Systems (AISs). Yet they expose the sector to typical cyber-domain threats: the IMO published Guidelines on Maritime Cyber Risk Management [6], the USA launched its National Maritime Cybersecurity Plan [7], and maritime cyberattacks rose 900% in three years [8], evidencing the need for tools mitigating cyber-electronic vulnerabilities [9].
Blockchain-based systems can leverage data security through decentralization and sophisticated encryption. Mainstream in finance for a decade [10], blockchain now spreads to military and other sectors securing critical systems. With IoT growing in autonomous shipping, navigation and monitoring [11], a secure reliable communication system is critical — and the e-navigation Strategy Implementation Plan [12] lists improved reliability and data integrity among shipboard user needs and priorities.
This work targets a national-scale MMS whose sensing devices are isolated and often in dangerous environments: attackers could tamper with physical sensors or RF channels, compromising integrity and authenticity [11], or SolarWinds-style [1] attacks could endanger MMS database availability. We propose a blockchain-based MMS securing integrity, authenticity and availability of vessel traffic sensing data, using the Raft consensus algorithm for fault tolerance with permissioned access via cryptography. We assess QoS in response time and data volume, and the feasibility and performance of blockchain clients on limited-resource, low-cost IoT devices — dockerizing the Raspberry Pi AIS client and varying hardware profiles. The contributions are: a functional permissioned-blockchain MMS prototype on Fabric with Raft receiving and securely storing AIS data; integration with a low-cost Brazilian Navy AIS receiver in a real environment; evaluation across client hardware configurations; and quantified blockchain overhead against desirable QoS levels.
Blockchain is a disruptive technology for trust among mutually distrusting parties [13–15]: a distributed, decentralized append-only ledger [16] over a peer-to-peer network, with cryptographically chained, replicated blocks, smart contracts [16], and consensus protocols ensuring integrity and consistency [14]. Consensus divides into proof-based (PoW, PoS, PoET — lottery-like, permissionless [15]) and vote-based (Byzantine/crash fault-tolerant — quorum of identified peers, i.e., permissioned blockchains [14]): proof-based aggregates more participants but poor throughput, while vote-based aggregates far higher throughput — even a hundred times faster [14,17]. Platforms include Bitcoin [13], Ethereum with Solidity smart contracts [19] (both permissionless), and Hyperledger Fabric [18] — modular, usually permissioned, with native Raft [14–16] crash-fault-tolerant leader-based consensus since 2018, tolerating failure while 50% plus one of the quorum functions.
In IoT and sensor networks, Al-Sahan et al. [20] built a permissioned Fabric surveillance system fusing heterogeneous stakeholders with facial-recognition machine learning; Melo et al. [21] compared Ethereum and Fabric for critical-infrastructure monitoring, finding Fabric slightly ahead in throughput, modularity and tooling; Bandara et al. [22] proposed a lightweight Kafka-consensus IoT blockchain with sharding; Gil et al. [23] used Docker containers to ease client setup and scalability; and Honar et al. [24] analyzed Fabric performance on resource-constrained IoT devices, optimizing throughput, latency and resource use while meeting security requirements.
For maritime cybersecurity, ref. [26] assesses cyber risks in ship navigation systems per IMO guidelines [6]; ref. [27] vulnerability-scans Integrated Navigation Systems (ECDIS, radar/ARPA, AIS); Kavallieratos et al. [28] elicit ECDIS/GMDSS/AIS security requirements via Secure Tropos [29] (preventing AIS loss, protecting voyage data, authenticating actors); Androjna et al. [30] document an Elba AIS spoofing attack with thousands of fake streams; and Goudossis et al. [31] and Kessler [32] propose symmetric/identity-based and public-key protected AIS (pAIS). All focus on on-board or ship-to-ship security — large-scale MMS integration remaining little explored. In blockchain-for-maritime, Rahimi et al. [11] secured buoy/UAV sensing via Ethereum with 13–18% delay and 12–16% throughput overhead; Zhang et al. [33] gained 8% security and 6% transaction speed in Maritime Transportation Systems; Jiang et al. [34] cut energy 78% with lightweight proof-of-stake for edge IoT. To our knowledge, no work implements a Fabric-permissioned blockchain in MMSs — the gap this work fills, evaluated in a real scenario with low-cost clients.
Maritime Domain Awareness (MDA) [35–37] studies events and military/non-military circumstances in the maritime environment from available data, mainly sensors: collision avoidance through obstacle detection and close-range encounter prediction is key to safe shipping. Authorities must monitor their domain and EEZ against illegal fishing, illicit traffic, pollution and piracy. AIS is the utmost monitoring tool: AIS stations in strategic coastal locations collect MMSI, name, position, speed and direction from ships within ~40 nautical miles, feeding organized views and machine-learning behavior prediction; radars and cameras complement it. SOLAS (IMO) requires AIS transponders on ships above 300 gross tonnage worldwide. Sensing devices may sit on buoys and UAVs with limited compute and energy, communicating over a WMAN mesh as relays [38] to a data fusion center per Naval District (ND), which aggregates and forwards data to the Naval Authority for storage in a centralized or distributed redundant database.
Sensors in remote places face tampering: GNSS, ECDIS and AIS threats to safety are well documented [30], motivating encrypted signals and robust cybersecurity. Our attack model spans four scenarios with known vulnerabilities (e.g., PostgreSQL CVE-2019-9193 [39]) and SolarWinds-style supply-chain techniques [1]: (1) availability attack — infiltrating the Naval Authority network via a supply-chain backdoor and exploiting database flaws, unable to hit all NDs; (2) integrity attack — a coerced insider's credentials used to covertly modify stored data; (3) collusion attack — compromised servers in several NDs cooperating to degrade routing, integrity and availability [40], short of corrupting all servers; (4) UAV hijacking — eavesdropping and spoofing unauthenticated UAV–operator RF links within coverage.
The blockchain-based MMS runs on Fabric for sensing-data integrity, authenticity and availability, with Docker-compacted blockchain clients and CPU/memory-limited containers for resource efficiency. Buoys and UAVs act as blockchain clients with MSP-managed cryptographic credentials; each carries the Brazilian Navy low-cost AIS receiver (VHF whip antenna, SDR demodulating dongle, Raspberry Pi 3). Clients send NMEA strings as transactions via the Python Fabric SDK [41,42] to endorsing peers in the responsible ND: endorsers verify authenticity/integrity, execute the smart contract (query, command or pre-storage processing), sign with private keys, and return endorsements; the client collects the policy's endorsement count — adjustable for security level at the cost of asymmetric-signing compute — and submits to the Raft orderer service, which orders blocks and broadcasts them for committer peers to verify and irreversibly append (Figures 1–3). Inconsistent transactions are quarantined for audit; ledger data become immutable.
Security analysis (Figure 4): the centralized MMS is vulnerable in all four scenarios (single point of failure; mutable database; no fault tolerance; unauthenticated UAV links). The decentralized-database MMS survives only the availability scenario. The blockchain-based MMS resists all four: distributed ledger defeats single-point failure; immutability defeats silent modification; Raft fault tolerance defeats collusion below 1/3–1/2 of nodes; asymmetric cryptography with MSP key management secures UAV–operator communications. The analysis generalizes to any sensor IoT network on conventional databases.
Covering large areas requires launching numerous devices in distinctive spots — so a methodology is needed to discover the minimum resources for a blockchain client application, avoiding the cost of buying and testing many devices and re-implementing the application in several IoT languages. The solution: build a Docker image with all client dependencies pre-compiled, then instantiate containers with varying CPU/memory limits — the host kernel handles container processes via namespaces and cgroups, so CPU and memory consumption per container can be constrained (default unlimited; constraints via the Linux CFS Scheduler [43]). Prior work validates containers for simulating IoT fleets and connected vehicles [44–46], including systematic Modeling and Simulation-as-a-Service reviews [46], but rarely details device-parameter configuration — the gap our Docker-compose approach fills.
Image preparation has two steps: (1) a Docker image from the Python repository on Docker Hub (Python 3.7 on Debian Buster for ARM, matching Raspberry Pi and Fabric Python SDK experience) with all client dependencies pre-compiled; (2) compiling the HyperLedger Fabric SDK and its dependencies — yielding a working, fast-starting, scalable environment, published on Docker Hub [47] with a README, Docker-compose.yaml example (resource limits under the deploy key) and Dockerfile example. Experiments then sweep CPU and memory boundaries to find the minimum viable configuration and detect where extra resources stop paying off — with containers re-instantiated per setup purely by editing Docker-compose.yaml.
The environment (Figure 5) connects the blockchain client (Raspberry Pi, right) to a virtualized Linux server (left, VirtualBox hypervisor [48] on macOS) with each blockchain entity isolated in its Docker container; prototype code is public on GitHub [49]. The server emulates a Naval District blockchain node (Intel Core i5 1.8 GHz, 2048 MB); the client Raspberry Pi 3 (Cortex-A53 quad-core 1.4 GHz, 1024 MB) receives NMEA sensing data over ports 7050–7054. The VHF whip antenna near Guanabara Bay (Rio de Janeiro) captured real maritime AIS traffic, demodulated by the SDR dongle into text entries; to simulate a large MMS, 1500 AIS entries were sent, representing 100 nodes × 15 entries per minute.
Blockchain overhead was benchmarked against SSH (both symmetric and asymmetric cryptography). Sending 1500 entries via SSH averaged 8% CPU (±5%) with ~7% OS load and ~156 MB memory (Figure 6a); via blockchain, 17% average CPU (±8%) with ~6% OS load and ~180 MB memory (Figure 6b) — an overhead of 9% CPU and 14.7% memory — while blockchain transmission was 60% faster (~60 s versus ~150 s). The client used only 17.6% of its 1024 MB and 16.9% of CPU: crucial, since sensing nodes on buoys/UAVs carry light payloads, face harsh weather and tampering, and lack server-grade resources. Server-side (Figure 7), the smart contract consumed just 3% CPU / 4.3 MB (only AIS verification logic), the endorser 11.7% CPU / 102 MB (asymmetric signing); all containers averaged 224.2 MB (11% of 2048 MB) and 34.4% CPU — meeting good QoS levels, with consumption growing with blockchain size while server power scales more easily than sensing nodes.
Dockerized clients were then benchmarked across hardware limits to find the resource-optimal point (all CPU percentages refer to one Raspberry Pi core): 200 AIS entries × 30 repetitions per setup. The client needs at least 18 MB memory and 10% CPU; above 30 MB memory, execution time barely improves, so higher memory was unexplored. Testing CPU limits of 10/30/50/70/90% against 18/20/25/30 MB (Figure 8) shows near-exponential transmission-time decline from 10% to 70% CPU, then a slight rise at 90% from Docker-vs-OS network-call resource competition — so 70% of one core is the compute-optimal setup. At 18–20 MB, used CPU rises from 50% to 70% allocation, while at 25–30 MB it steadily declines (Figure 9a); the performance colormap (Figure 9b) shows 70% CPU with 25 MB or 30 MB equally fast, but 30 MB consumes more CPU — hence 25 MB is the efficiency-optimal memory size, reducing hardware cost, energy and deployment/maintenance expense at nation scale. Robustness, we stress, comes primarily from peer count and redundancy rather than individual hardware power.
Most naval systems in operation — including communication, navigation and monitoring — are poorly mature in cybersecurity. To reduce vulnerabilities, this paper presented a blockchain-based MMS model leveraging security and ensuring sensing-data integrity, authenticity and availability. We successfully developed a permissioned blockchain prototype on the HyperLedger Fabric platform, made publicly available so other researchers can replicate the experiment; the security analysis showed how blockchain mitigates MMS vulnerabilities.
We integrated the prototype with a low-cost AIS receiver developed by the Brazilian Navy and sent 1500 real AIS entries to simulate MMS operation in a real environment. Despite increased CPU and memory consumption, the overhead stays at an acceptable QoS level, justified by the data-security gains. Our dockerized blockchain client enables smart resource consumption on sensing nodes while easing wide-scale IoT network scalability problems; the experiments identified an optimal client configuration — 70% of one Raspberry Pi core with 25 MB of memory — reducing deployment and maintenance costs with efficient resource use. Beyond MMS cybersecurity, the solution, code and hardware-configuration methodology extend to other large-scale maritime sensor systems such as environmental monitoring, wireless sensor networks and IoT technologies, with cost and energy-efficiency benefits.
In future work, we plan to scale the prototype to a full MMS capable of monitoring a whole country's coast — so far integrating only AIS, with heterogeneous sensing systems still to be added. A further direction fuses blockchain decentralization with AI data analysis/decision-making: an MMS evolving into a command-and-control system assisting naval decision-making, with on-chain smart contracts implementing AI algorithms for strong processing and fast, precise operational insights under critical security requirements.