چکیده – این مقاله یک چارچوب آزمون یکپارچه (Integrated Testing Framework) برای سامانه‌های اینترنت اشیا (Internet of Things – IoT) ارائه می‌دهد که بر پایه بستر متن‌باز RIVER توسعه یافته است. هدف ما بهره‌گیری از روش‌های موجود فازینگ هدایت‌شده (Guided Fuzzing) مبتنی بر تکنیک‌های هوش مصنوعی (Artificial Intelligence – AI) برای آزمون برنامه‌های کاربردی اینترنت اشیا است که به‌صورت سرتاسری (End-to-End) مستقر شده‌اند. ابتدا معماری چارچوب، همراه با رابط آن با برنامه کاربردی کاربر، تعریف می‌شود. سپس، جزئیات فنی بهره‌گیری از روش‌های اجرای کانکولیک (Concolic Execution) در آزمون برنامه‌های کاربردی اینترنت اشیا ارائه می‌گردد. معماری آزمون به‌صورت یک گراف (Graph) از فرایندهای متصل به یکدیگر که بر روی دستگاه‌های فیزیکی مستقر شده‌اند، مدل‌سازی می‌شود. روش‌های مورد استفاده، قابلیت آزمون فرایندهای منفرد را به‌صورت مجزا گسترش می‌دهند. چارچوب جدید پیشنهادی به کاربر امکان می‌دهد علاوه بر آزمون تعامل میان فرایندها، اتصالات پویا (Dynamic Connections) را نیز که ممکن است در زمان اجرای برنامه کاربردی مستقرشده و در حین زمان اجرا (Runtime) ایجاد شوند، مورد آزمون قرار دهد.

واژگان کلیدی (Index Terms): اینترنت اشیا (IoT)، آزمون (Testing)، فازینگ (Fuzzing)، اجرای کانکولیک (Concolic)، نمادین (Symbolic)، استقرار (Deployment)

۱. مقدمه (INTRODUCTION)

اینترنت اشیا (Internet of Things – IoT) را می‌توان به‌طور کلی به ‌عنوان شبکه‌ای از دستگاه‌های به‌هم‌پیوسته توصیف کرد که با افزودن قابلیت‌های دیجیتال به تجهیزات موجود، عملکردهای آن‌ها را ارتقا می‌دهند، یا با ایجاد ارتباط میان رایانش سطح پایین (Low-Level Computing) و حسگرها (Sensors) با اینترنت و رایانش ابری (Cloud)، برنامه‌های کاربردی جدیدی را ایجاد می‌کنند. با توجه به اینکه اینترنت اشیا یک فناوری نوظهور به شمار می‌رود، تأمین امنیت رایانشی (Computing Security) برای تضمین پذیرش و به‌کارگیری سریع آن از اهمیت بالایی برخوردار است.

یک سامانه پیچیده اینترنت اشیا (IoT) ممکن است شامل تعداد زیادی دستگاه ناهمگون (Heterogeneous Devices) باشد که از طریق شبکه‌های مختلف و با استفاده از مجموعه متنوعی از پروتکل‌ها (Protocols) به یکدیگر متصل شده‌اند؛ پروتکل‌هایی که اغلب داده‌های حساس را منتقل می‌کنند. این مسئله خطر رفتار مخرب (Malicious Behavior) را افزایش داده و امکان بهره‌برداری (Exploitation) از سامانه را ایجاد می‌کند. اگرچه تعریف استاندارد و واحدی برای معماری شبکه‌های اینترنت اشیا (IoT Networks) وجود ندارد، این شبکه‌ها دارای ویژگی‌های مشترک زیر می‌باشند:

الف) موجودیت‌ها (Entities): طیف گسترده‌ای از دستگاه‌ها، مانند حسگرها (Sensors)، عملگرها (Actuators) یا ترکیبی از هر دو [1].

ب) شبکه محلی (Local Network): شبکه‌ای که وظیفه هماهنگ‌سازی و کنترل «اشیا» (Things) را بر عهده دارد؛ برای مثال، واحد کنترل الکترونیکی (Electronic Control Unit – ECU) خودرو.

ج) اینترنت (Internet): بستری که در آن داده‌های تجمیع ‌شده (Aggregated Data) به اطلاعات(Information) تبدیل می‌شوند.

الگوی رایج در سامانه‌های اینترنت اشیا (IoT) شامل شبکه‌ای مش‌مانند (Mesh) از دستگاه‌های اینترنت اشیا با قابلیت‌های محدود (Low-Functionality) است که در انجام یک یا چند وظیفه مشخص عملکرد بسیار خوبی دارند و با یک هاب مورد اعتماد (Trusted Hub) ارتباط برقرار می‌کنند. شرکت‌های بزرگ فناوری در حوزه برنامه‌های کاربردی اینترنت اشیا (IoT) با تمرکز بر مصرف‌کنندگان، در زمینه خانه‌های هوشمند (Smart Homes) با یکدیگر رقابت می‌کنند و محصولاتی مانند دستیار خانگی گوگل (Google Home Assistant)، آمازون الکسا (Amazon Alexa) و پورتال فیس‌بوک (Facebook Portal) را معرفی کرده‌اند. استفاده گسترده از تعداد محدودی هاب که به دستگاه‌های شخصیِ دارای اعتمادپذیری آسان (Easily Trusting) متصل می‌شوند، این هاب‌ها را به اهدافی ارزشمند و جذاب برای مهاجمان (Attackers) تبدیل کرده است [2].

فازینگ (Fuzzing) یک تکنیک آزمون خودکار (Automated Testing) است که تعداد زیادی ورودی (Inputs) تولید کرده و آن‌ها را به سامانه تحت آزمون (System Under Test – SUT) ارسال می‌کند تا خرابی‌ها (Crashes) یا آسیب‌پذیری‌ها (Vulnerabilities) را شناسایی کند. بزرگ‌ترین چالش‌ها در فازینگ اینترنت اشیا (IoT Fuzzing)، مهارگری کارآمد (Efficient Harnessing) یا شبیه‌سازی (Emulation) دستگاه اینترنت اشیا (IoT Device) برای به حداکثر رساندن توان عملیاتی ورودی‌ها (Input Throughput)، و تنظیم مولد ورودی (Input Generator) فازر (Fuzzer) به‌ گونه‌ای است که هم پوشش گسترده (Broad Coverage) و هم پوشش عمیق (Deep Coverage) از سامانه تحت آزمون (SUT) حاصل شود.

در حال حاضر، معماری‌های پیشرفته موجود (State-of-the-Art Architectures) عمدتاً رویکرد «جعبه خاکستری» (Grey Box Approach) را ترجیح می‌دهند [3]؛ به این معنا که فازر ورودی‌های کاملاً تصادفی تولید نمی‌کند، بلکه تولید موارد آزمون (Test Cases) را بر اساس اطلاعات مختلفی که به‌صورت پویا (Dynamically) یا ایستا (Statically) جمع‌آوری شده‌اند، هدایت می‌کند [4] [5].

با توجه به افزایش حجم داده‌های تولید شده توسط دستگاه‌های اینترنت اشیا (IoT)، رایانش لبه‌ای (Edge Computing) به‌ عنوان راهکاری نوظهور مطرح شده است که با قرار دادن گره‌های واسط (Intermediary Nodes) میان دستگاه‌های دارای قابلیت‌های محدود (Low-Functionality Devices) و رایانش ابری (Cloud)، می‌تواند «بار محاسباتی را از مرکز داده متمرکز (Centralized Data Center) دور کرده و به‌طور قابل‌توجهی تأخیر در تبادل پیام (Message Exchange) را کاهش دهد» [6].

افزودن یک لایه جدید به ارتباطات، سطح حمله (Attack Surface) سامانه اینترنت اشیا (IoT System) را افزایش می‌دهد و این سامانه می‌تواند آسیب‌پذیری‌های دستگاه‌های مستقر در سطح میانی (Middle Level) را نیز به ارث ببرد [7]. مقاله ما بهبودی را پیشنهاد می‌کند که به آزمونگر (Tester) امکان می‌دهد موارد آزمون (Test Cases) مربوط به دستگاه‌های لبه‌ای (Edge Devices) را نیز در فرایند آزمون وارد کند تا از بروز آسیب‌پذیری‌ها (Vulnerabilities) به شکل مؤثرتری جلوگیری شود.

با توجه به مجموعه چالش‌های جدیدی که این فناوری‌های نوظهور ایجاد کرده‌اند، برای ایمن‌سازی سامانه‌های توزیع‌شده یکپارچه (Integrated Distributed Systems) به رویکردهای جدیدی نیاز است. نوآوری (Novelty) رویکرد ما را می‌توان به‌صورت زیر خلاصه کرد:

تا آنجا که ما اطلاع داریم، این نخستین مقاله‌ای است که به مسئله فازینگ (Fuzzing) برنامه‌های کاربردی اینترنت اشیا (IoT) مستقر شده به‌ صورت سرتاسری (End-to-End) می‌پردازد.

ما یک نمونه اولیه متن‌باز (Open-Source Prototype) با نام RiverIoT ارائه می‌کنیم که جامعه پژوهشی و فنی می‌تواند آن را مورد استفاده و آزمون قرار دهد. این نمونه اولیه بر بستر چارچوب River موجود ما توسعه یافته است: https://river.cs.unibuc.ro
RiverIoT قادر است فازینگ (Fuzzing) را در سه سطح متفاوت انجام دهد:

گراف (Graph) نمایش‌دهنده برنامه کاربردی مستقر شده اینترنت اشیا (IoT Deployed Application)؛ یعنی تغییر گره‌ها (Nodes) و یال‌ها (Edges) درون برنامه کاربردی مستقر شده است.
سطح هر گره (Node’s Level).
اتصال متقابل گره‌های ورودی/خروجی (Interconnection of Input/Output Nodes) میان گره‌های مختلف و ارتباطات (Communication) میان آن‌ها؛ یعنی اینکه چگونه یک گره می‌تواند تحت تأثیر سایر گره‌هایی قرار گیرد که اتصال ورودی (Input Connection) آن را ایجاد می‌کنند، یا اینکه کانال ارتباطی (Communication Channel) میان آن‌ها چگونه عمل می‌کند.

ساختار مقاله به شرح زیر است. در بخش بعدی، برخی از پژوهش‌های پیشین در این حوزه بررسی می‌شوند که بر روش‌های ما تأثیر گذاشته‌اند یا انگیزه انجام این پژوهش را فراهم کرده‌اند. بخش ۳ ورودی‌های موردنیاز از سوی مالک یک برنامه کاربردی اینترنت اشیا (IoT Application) را برای آزمون آن با استفاده از چارچوب پیشنهادی ما توصیف می‌کند. بخش ۴.۳ معماری و روش‌های پیشنهادی برای بهره‌گیری از اجرای کانکولیک (Concolic Execution) و تکنیک‌های فازینگ هدایت‌شده (Guided Fuzzing) را تعریف می‌کند. همچنین، جزئیات پیاده‌سازی (Implementation Details) و شبیه‌سازی (Simulation) بر روی دستگاه‌های اختصاصی (Dedicated Devices) ارائه می‌شود. در نهایت، بخش ۵ به ارائه نتیجه‌گیری‌ها (Conclusions) و برنامه کارهای آینده (Future Work Plan) اختصاص دارد.

۲. کارهای مرتبط (Related Work)

رویکردهای اخیر در زمینه امنیت اینترنت اشیا (IoT Security) به این نتیجه رسیده‌اند که آزمون فازینگ (Fuzz Testing) می‌تواند آسیب‌پذیری‌های واقعی (Real-Life Vulnerabilities) را در سامانه‌های موجود شناسایی کند. FIRM-AFL [3] یک پیاده‌سازی اختصاصی برای اینترنت اشیا (IoT-Specific Implementation) است که بر روی فازر AFL اجرا می‌شود. این روش با بهره‌گیری هم‌زمان از شبیه‌سازی در سطح کاربر (User-Mode Emulation) و شبیه‌سازی در سطح سامانه (System-Mode Emulation)، کارایی توان عملیاتی آزمون (Test Throughput) را بهبود می‌دهد. این پیاده‌سازی با آزمون مجموعه‌داده‌های موجود (Existing Datasets) مربوط به میان‌افزار لینوکس (Linux Firmware) و دستگاه‌های مسیریاب (Router Devices) ارزیابی شده است.

پس از آنکه کد به‌صورت پویا توسط فازر ابزارگذاری (Dynamically Instrumented) می‌شود، ورودی به دستگاه شبیه‌سازی‌ شده (Emulated Device) ارسال می‌شود. بااین‌حال، به دلیل ماهیت اختصاصی و انحصاری بسیاری از دستگاه‌ها، ابزارگذاری کد منبع (Source Code Instrumentation) همیشه فرایندی سرراست و ساده نیست.

رویکردهای دیگری مانند IoTFuzzer [8] ایده جهش (Mutation) در پیام‌های برنامه کاربردی موبایل (Mobile Application) را که دستگاه اینترنت اشیا (IoT Device) با آن تعامل دارد، مورد آزمون قرار داده‌اند. در نهایت، AFLNet [9] پیاده‌سازی‌ای از AFL است که به‌طور خاص با هدف یافتن آسیب‌پذیری‌ها در نحوه پیاده‌سازی پروتکل‌های ارتباطی (Communication Protocols) توسط نرم‌افزار طراحی شده است. این روش از این واقعیت بهره می‌گیرد که یک پروتکل با پیاده‌سازی ضعیف (Poorly Implemented Protocol) می‌تواند منجر به ایجاد آسیب‌پذیری شود.

Skyfire [10] یک مولد بذر مبتنی بر داده (Data-Driven Seed Generator) برای ورودی‌های فازینگ (Fuzz Inputs) است که از دستور زبان (Grammar) ورودی‌های دارای ساختار پیچیده و مشخص استفاده می‌کند تا بذرهای معتبر و خوش‌ساخت (Well-Formed Seeds) را جهش (Mutate) داده و پوشش کد (Code Coverage) را بهبود دهد. این پژوهش تأیید می‌کند که ارائه یک توصیف ورودی (Input Description) می‌تواند جهش‌های کوچک‌گام (Small-Step Mutations) فازرهای عمومی (Generic Fuzzers) را با جهش‌های بزرگ‌گام (Big-Step Mutations) مبتنی بر دستور زبان تکمیل کند؛ و این قابلیت تنها به نوع داده (Data Type) محدود نمی‌شود.

آزمون مبتنی بر دستور زبان (Grammar-Based Testing) همچنین محور اصلی پژوهش Zeller و Gopinath با عنوان Building Fast Fuzzers [11] است که در آن، سرعت تولید ورودی‌های معتبر فازشده (Fuzzed Valid Inputs) بهینه‌سازی می‌شود.

یکی از چالش‌های اصلی فازینگ دستگاه‌های اینترنت اشیا، وابستگی میان‌افزار به سخت‌افزار (Hardware-Dependence of Firmware) است. P2IM [12] چارچوبی را برای غلبه بر این محدودیت پیشنهاد می‌کند. این چارچوب تلاش می‌کند یک سامانه افزونه‌ای (Plugin System) فراهم کند که امکان اجرای پیوسته یک باینری میان‌افزار (Firmware Binary) را برای فازرهای آماده و عمومی (Off-the-Shelf Fuzzers) فراهم سازد.

P2IM با نظارت بر درخواست‌های خواندن/نوشتن (Read/Write Requests) روی ثبات‌ها (Registers)، یک مدل تجهیزات جانبی (Peripheral Model) را بر اساس دسته‌بندی ثبات‌هایی که میان‌افزار به آن‌ها دسترسی پیدا می‌کند، تولید می‌کند. P2IM برای دسترسی به ثبات‌های نگاشت ‌شده در حافظه (Memory-Mapped Registers) از شبیه‌ساز پردازنده (Processor Emulator) QEMU¹ استفاده می‌کند. این موضوع پیامدی برای ادعای اولیه آن‌ها درباره امکان استفاده از فازرهای آماده و عمومی دارد: برای اینکه بتوان فازر موردنظر را به‌صورت افزونه (Plugin) به چارچوب متصل کرد، فازر باید قابلیت یکپارچه‌سازی با QEMU را فراهم کند. در آزمایش‌های خود، P2IM از TriforceAFL² برای اتصال به حالت شبیه‌سازی کامل سامانه (Full-System Emulation Mode) در QEMU استفاده می‌کند.

P2IM گامی در جهت درست محسوب می‌شود، اما از نبود دسترسی مستقیم به حافظه (Direct Memory Access) و همچنین وابستگی شدید به چیدمان سخت‌افزاری (Hardware Layout) سامانه تحت آزمون (System Under Test – SUT) رنج می‌برد.

HALucinator [13] مدل به‌شدت وابسته P2IM را به چالش می‌کشد و یک مدل جداسازی (Decoupling Model) میان سخت‌افزار و میان‌افزار سامانه‌های نهفته (Embedded Systems) پیشنهاد می‌کند. این چارچوب با تکیه بر این واقعیت که توسعه‌دهندگان میان‌افزار معمولاً کد را با استفاده از لایه‌های انتزاعی (Abstractions)، مانند لایه‌های انتزاع سخت‌افزار (Hardware Abstraction Layers – HALs)، توسعه می‌دهند، چارچوبی را پیشنهاد می‌کند که با پیاده‌سازی شبیه‌سازی سطح بالا (High-Level Emulation – HLE) و ایجاد هوک‌ها (Hooks) برای توابع ارائه‌شده توسط HALها، این جداسازی را محقق می‌سازد.

تلاش‌های هدایت ‌شده توسط صنعت (Industry-Led Efforts) به توسعه استانداردهای ورودی/خروجی اینترنت اشیا (IoT I/O Standards) منجر شده‌اند؛ از جمله مجموعه استانداردهای عمومی MIPI (MIPI General-Purpose Set of Standards) [14] یا پروتکل ONVIF Profile M برای ارتباط دوربین‌های IP در محیط اینترنت اشیا [15]. با این ‌حال، هر دوی این موارد بسته و غیرمتن‌باز (Closed Source) هستند و در نتیجه، دسترسی به آن‌ها برای بررسی و ارزیابی دانشگاهی (Academic Scrutiny) محدودتر است.

Phan و Kim در زمینه دستگاه‌های خانه هوشمند (Smart Home Devices)، یک پلتفرم گیت‌وی (Gateway Platform) پیشنهاد کرده‌اند که امکان دامنه گسترده‌تری از ارتباط متقابل (Interconnectivity) میان دستگاه‌های اینترنت اشیا را فراهم می‌کند. بااین‌حال، رویکرد آن‌ها نسبتاً جعبه سفید (White Box) است؛ به این معنا که توسعه‌دهنده یک پروفایل دستگاه (Device Profile) را در اختیار آزمونگر (Tester) قرار می‌دهد و این پروفایل به آزمونگر امکان می‌دهد به ساختار ورودی/خروجی (I/O Structure) دستگاه دسترسی پیدا کرده و آن را درک کند.

W3C یک مدل استاندارد برای توصیف فراداده (Metadata) و رابط‌های اشیا (Things) پیشنهاد می‌کند. این مدل، مشابه پیشنهاد ما، با استفاده از JSON مدل‌سازی شده و می‌تواند ورودی/خروجی دستگاه‌های اینترنت اشیا را توصیف کند. مشخصات ارائه ‌شده توسط W3C هنجاری (Normative) هستند، زیرا مدلی را پیشنهاد می‌کنند که فروشندگان اینترنت اشیا (IoT Vendors) باید از آن پیروی کنند؛ در حالی که مدل ما مدلی است که تلاش می‌کند مشخصات دستگاه‌های موجود را توصیف کند.

در مقاله‌ای که در [16] ارائه شده و چهار چارچوب اینترنت اشیا (IoT Frameworks) تسهیل‌کننده ساخت سامانه‌های اینترنت اشیا را تحلیل کرده است، پژوهشگران دریافتند که هیچ‌یک از چارچوب‌های انتخاب‌شده امکان مشخص‌کردن محدودیت‌های سخت‌افزاری (Hardware Constraints) مورد انتظار برای دستگاه‌هایشان را فراهم نمی‌کنند؛ موضوعی که در اینترنت اشیا اهمیت زیادی دارد، زیرا بسیاری از دستگاه‌ها دارای قابلیت‌های سخت‌افزاری محدود (Limited Hardware Capabilities) هستند.

۳. مشخصات موردنیاز کاربر برای استفاده از چارچوب RiverIoT (User Specification for Using the RiverIoT Framework)

در این بخش توضیح داده می‌شود که کاربر باید سامانه اینترنت اشیا (IoT System) خود را چگونه توصیف کند تا چارچوب RiverIoT بتواند آن را تحت آزمون فازینگ (Fuzz Testing) قرار دهد.

۳.۱ مبانی (Basics)

فرض می‌کنیم که معماری یک برنامه کاربردی اینترنت اشیا (IoT Application) دارای مشخصاتی برای اتصال ورودی/خروجی (Input/Output Connection Specification) است که می‌توان آن را به‌صورت یک گراف جهت‌دار (Oriented Graph) به شکل زیر نمایش داد:

گره‌ها (Nodes) یعنی V: دستگاه‌های فیزیکی (Physical Devices) هستند که هر یک از آن‌ها دارای یک بخش از نرم‌افزار دودویی (Binary Software) یا فرایند (Process) مستقرشده و در حال اجرا می‌باشد.
یال‌ها (Edges) یعنی E: از یک گره به گره دیگر جهت‌دهی می‌شوند و مسیر انتقال خروجی (Output) یک دستگاه به ورودی (Input) دستگاه دیگر را مشخص می‌کنند. به‌صورت صوری، برای هر گره v ∈ V، مجموعه‌ای از یال‌های ورودی (Incoming Edges) به شکل Vin(v) = {vin ∈V | (vin, v) ∈ E} تعریف می‌شود و مجموعه‌ای از یال‌های خروجی (Outgoing Edges) نیز به صورت Vout(v) = {vout ∈V | (v, vout) ∈ E} تعریف می‌شوند.

گراف G در زمان اجرا (Runtime) پویا (Dynamic) در نظر گرفته می‌شود و این قابلیت را دارد که گره‌ها (Nodes) یا یال‌ها (Edges) در آن تغییر کنند. انگیزه استفاده از این ساختار آن است که یک برنامه کاربردی اینترنت اشیا در طول زمان اجرای خود می‌تواند بسته به شرایط مختلف، به‌ صورت پویا تغییر کند؛ برای مثال، افزودن یا حذف فیلترها (Filters) میان گره‌ها بر اساس تاریخ/زمان، یا افزودن و حذف اتصالات (Connections) با هدف برطرف‌کردن مشکلات بافرینگ (Buffering) در سامانه.

بافرهای ورودی و خروجی(Input and Output Buffers) کامل یک فرایند باینری (Binary Process) مستقر در گره v را به ‌ترتیب با Buf f erin(v) و Buf f erout(v) نمایش می‌دهیم. از آنجا که یک گره v می‌تواند چندین اتصال ورودی یا خروجی داشته باشد، این بافرها در واقع اجتماع (اتحاد) مرتب ‌شده (Ordered Union) بافرهایی هستند که از گره‌های متصل خارج یا به آن‌ها وارد می‌شوند. به عنوان مثال:

Buf f erin(v) = ∪vin∈Vin(v)Buf f erout(vin), به ترتیب Buf f erout(v) = ∪vout∈Vout(v)Buf f erin(vout).

۳.۲ مشخصات گراف (Graph Specification)

با تشریح تعاریف ارائه ‌شده در بخش قبل، کاربر باید یک گراف سازگاری (Compatibility Graph) با نام Gtotal(V, E) مشخص کند که شامل مجموعه تمامی گره‌ها (Nodes) و یال‌هایی (Edges) باشد که ممکن است در هر زمان در طول اجرای برنامه کاربردی مستقر شده اینترنت اشیا (IoT Deployed Application) وجود داشته باشند. در هر لحظه، تنها زیرمجموعه‌ای از این گراف، یعنی G ∈ Gtotal، در واقع توسط برنامه کاربردی مورد استفاده قرار می‌گیرد و مجموعه گره‌ها و یال‌های استفاده ‌نشده در آن لحظه از اجرای برنامه، به‌ عنوان گره‌ها و یال‌های اختیاری (Optional) یا استفاده‌ نشده (Unused) در نظر گرفته می‌شوند.

ما معتقدیم ساختار GtotalG قابلیت‌های استقرار (Deployment Capabilities) را محدود نمی‌کند، زیرا فروشندگان نرم‌افزار (Software Vendors) لازم است در هر زمان یک نمای کلی (Overview) از پشته نرم‌افزاری و سخت‌افزاری (Software and Hardware Stack) قابل استقرار در اختیار داشته باشند. بدیهی است که گراف در نسخه‌های (Releases) مختلف، می‌تواند تغییر کند و روش‌های ما نیز می‌توانند خود را با این تغییرات سازگار سازند. مشخصات موردنیاز کاربر شامل موارد زیر است که توصیف بصری آن در شکل ۱ ارائه شده است.

مجموعه تمامی گره‌ها V و فرایند باینری (Binary Process) که باید بر روی هر یک از آن‌ها اجرا شود، یعنی P (v), ∀ v ∈ V.
مجموعه گره‌های بدون وابستگی (No-Dependency Nodes) با نماد Vinit؛ یعنی گره‌هایی که به ‌عنوان حسگرها (Sensors) یا فرایندهای جمع‌آوری داده (Data Gathering Processes) در نظر گرفته می‌شوند و نباید هیچ اتصال ورودی (Input Connection) واردشونده‌ای داشته باشند.
برای هر گره (v \in V): قالب ورودیِ بافرهای ورودی و خروجی، به‌ترتیب Buffer_in (v) و Buffer_out(v).

منظور از قالب، ابعاد هر یک از این بافرها، اجزای تشکیل‌دهنده آن‌ها و طول هر یک از اجزای منفرد است؛ برای مثال، بخش نخست ورودی یک هدر تصویر (Image Header)، بخش دوم خود بافر تصویر (Image Buffer)، و بخش پایانی برخی فراداده‌های کاربر (User Metadata) مربوط به تصویر است. همچنین، قالب شامل دیکشنری داده (Data Dictionary) تشکیل‌دهنده بافر و سایر جزئیات اختیاری (Optional Details) است که می‌توانند به هدایت بهتر فرایند فازینگ کمک کنند. جزئیات فنی بیشتر در بخش ۳.۳ مشخص شده‌اند.

مجموعه اولیه گره‌ها V_r و یال‌ها E_r که نمی‌توان آن‌ها را با موارد دیگری جایگزین کرد یا از معماری حذف نمود. انگیزه این امر آن است که از آنجا که روش فازینگ (Fuzzing Method) ما می‌تواند گراف اتصال‌دهنده (Connecting Graph) برنامه کاربردی را تغییر دهد، کاربر می‌تواند بخشی از معماری اولیه خود (یا حتی تمام آن را) به‌ عنوان بخش ثابت (Fixed) برای فرایند آزمون مشخص کند.

۳.۳ توصیف مشخصات ورودی (Input Specification Description)

ما یک نمونه مشخصات (Specification) را طراحی کرده‌ایم (لیست ۱) که به‌اندازه کافی انعطاف‌پذیر است تا بتواند طیف متنوعی از سامانه‌های اینترنت اشیا (IoT Systems) را مدل‌سازی کند. مؤلفه سطح بالاتر (Higher-Level Component) این مشخصات، گراف سازگاری (Compatibility Graph) گره‌های اینترنت اشیا (IoT Nodes) در شبکه مش (Mesh) را توصیف می‌کند. برای به حداقل رساندن تلاش آزمونگر (Tester) در ایجاد سناریوهای آزمون (Test Scenarios)، این مشخصات نسبت به انواع داده (Data Types) یا پروتکل‌های (Protocols) مورد استفاده برای ارتباط داده‌ای، حداقل وابستگی و توجه را دارد و فرض می‌کند که:

				
					∀ vi ∈ V, ∃vj , (vi vj ) ∈ E

یک نمونه ساده و آموزشی از مشخصات گراف (Graph Specification) در لیست ۱ ارائه شده است.

لیست ۱. نمونه‌ای از مشخصات گراف سازگاری (Compatibility Graph):

				
					{
	"configuration-name": "Generic Network",
	"iot-nodes": {
		"1": { // Buffer description },
		"2": { ... }
	},
	"io-edges": {
		"1": {
			"vout": 3, // Output node
			"vin": 1, // Input node
			"vout-buffer": 1, // Buffer id
				sending the data
			"vin-buffer": 2 // Buffer id
				receiving the data
			"edge-prob": 66
		},
		"2": {
			vout": 2,
			"vin": 1,
			"vout-buffer": 2, // Buffer
				receiving the data
			"vin-buffer": 1,
			"edge-prob": 20
		}
	}
}

پارامتر «iot-devices» برای هر یک از دستگاه‌ها، هم شامل اطلاعات ارتباطی (Communication Information) مربوط به بافرهای (Buffers) دستگاه است و هم اطلاعات اختیاری (Optional Information) را دربر می‌گیرد که می‌تواند عملکرد فازر (Fuzzer) را در آزمون یک دستگاه خاص بهبود دهد. بسیاری از دستگاه‌های اینترنت اشیا (IoT Devices) دارای چندین بافر ورودی و خروجی (Input and Output Buffers) هستند که یا از چندین حسگر (Sensors) ناشی می‌شوند یا نقاط پایانی (Endpoints) ارتباطی برای برقراری ارتباط با سایر دستگاه‌ها هستند. مشخصات (Specification) شامل تمام بافرهایی خواهد بود که برای سناریوی آزمون (Testing Scenario) مرتبط هستند.

هر بافر ورودی (Input Buffer) یا با استفاده از یک نمونه (Instance) از فازر موردنظر آزمونگر (Tester’s Preferred Fuzzer) مورد فازینگ (Fuzzing) قرار می‌گیرد، یا ورودی را از منبع دیگری، برای مثال یک دستگاه دیگر، دریافت می‌کند. یک نمونه از مشخصات ورودی (Input Specification) در قالب JSON در لیست ۲ توصیف شده است.

لیست ۲. مشخصات بافرهای یک دستگاه (Single Device Buffers):

				
					{
	"device-name": "An IP Camera",
	"optional": "false",
	"class": "camera",
	"buffers": {
		"1": {
			"token-delimitators": " ",
			"protocol": "HTTP",
			"protocol-setting": "http://192.16
				8.0.112:8080/",
			"buffer-tokens":
			[{
				"name": "Camera command",
				"description": "Input that
					selects command",
				"token-type": "string",
				"byte-size": 256,
				"regex-rule": "", // Optional
					parameter to guide fuzzer
					generator
				"optional": false
			},
			{
				"name": "Camera parameter",
				"description": "Parameters for
					the command chosen",
				"token-type": "string",
				"byte-size": 256,
				"regex-rule": "[a-zA-Z]+=[a-zA
					-Z0-9]+",
				"optional": true
			}]
		},
	}
}

RiverIoT Symbolic اجرای کانکولیک اینترنت اشیا رایانش لبه‌ای فازینگ فازینگ هدایت‌ شده نمادین — شکل ۱. شکل، نمونه‌ای از یک گراف سازگاری (Compatibility Graph) ممکن درون برنامه کاربردی اینترنت اشیای (IoT Application) کاربر را نشان می‌دهد. یک نگاشت شهودی به یک برنامه کاربردی عملی می‌تواند به‌صورت زیر باشد: گره‌های S0، S1 و S2 می‌توانند گره‌های حسگر (Sensor Nodes) باشند که ورودی‌های خود را از دوربین‌های ویدئویی (Video Cameras) دریافت می‌کنند. گره‌های F0، F1 و F2 گره‌های فیلتر (Filter Nodes) هستند که در صورت تمایل کاربر و بر اساس کلیدهای برخط (Online Switches)، می‌توانند تصویر را به‌صورت اختیاری فیلتر کنند. C ، هاب مرکزی (Central Hub) است که تمامی گره‌ها را به یکدیگر متصل می‌کند. P0 و P1 گره‌های پردازشی (Processing Nodes) در نظر گرفته می‌شوند که می‌توانند تصاویر را دریافت کرده و به ‌نوعی پردازش کنند؛ برای مثال، شناسایی رویدادهای غیرعادی (Abnormal Events) در دنباله‌ای از تصاویر/ویدئوها. در نهایت، O1 و O2 گره‌هایی هستند که برخی نتایج را به یک رابط گرافیکی (Graphical Interface) یا یک پایگاه داده گزارش‌ها (Logs Database) درون یک سرور خروجی می‌دهند. مجموعه گره‌ها و یال‌های محدودشده (Restricted Nodes and Edges) با خطوط و دایره‌های پیوسته (Continuous Lines and Circles) نشان داده شده‌اند، در حالی که خطوط ناپیوسته (Discontinuous Lines) نشان‌دهنده اختیاری‌بودن (Optional) است. به‌طور مشخص: Vr = {S0, C, P0, O1}, Er = {S0− > C, C− > P0, P0− > C, C− > 01} . سایر گره‌ها و یال‌ها اختیاری (Optional) در نظر گرفته می‌شوند و می‌توانند در زمان اجرا (Runtime)، بسته به درخواست کاربر یا کد منبعی (Source Code) که آن‌ها را فعال می‌کند، به‌صورت پویا (Dynamically) به گراف افزوده شوند. مجموعه گره‌های بدون وابستگی (No-Dependency Nodes) از S0، S1 و S2 تشکیل شده است.

جدول ۱. توصیف بافر دستگاه (Device’s Buffer Description)

جدول ۱ خلاصه‌ای از فیلدهای موجود در مشخصات بافر (Buffer Specification) را ارائه می‌کند. برخلاف رویکردهای پیشین، مانند رویکرد Phan و Kim [14] که یک پروفایل دستگاه (Device Profile) را برای کل دستگاه اینترنت اشیا (IoT Device) ایجاد می‌کنند، RiverIoT تنها به ورودی/خروجی (I/O) دستگاهی نیاز دارد که تحت آزمون قرار می‌گیرد و بدین ترتیب، آزمونگر (Tester) می‌تواند آسیب‌پذیری‌ها (Vulnerabilities) را هدفمندتر شناسایی کند. کارهای آینده در زمینه این مشخصات می‌تواند شامل طراحی قالب‌هایی (Templates) برای پروتکل‌های ارتباطی (Communication Protocols) باشد که به آزمونگر امکان می‌دهد مشخصات را با سرعت بیشتری ایجاد و آماده‌سازی کند.

۴. روش‌های مورد استفاده برای آزمون (Methods Used for Testing)

با استفاده از مفروضات و مشخصات کاربر (User’s Specification) تعریف ‌شده در بخش ۳.۱، چارچوب RiverIoT می‌تواند فازینگ (Fuzzing) را در سطوح مختلف انجام دهد که در ادامه توضیح داده می‌شوند.

۴.۱ فازینگ در هر گره (Fuzzing at Each Node)

برای هر گره ممکن v ∈ V ، می‌توان از بستر موجود River برای انجام فازینگ هدایت‌ شده (Guided Fuzzing) به‌صورت مجزا استفاده کرد و هر برنامه باینری (Binary Program) را که می‌تواند بر روی یک دستگاه فیزیکی (Physical Device) مستقر شود، مورد آزمون قرار داد. چندین روش برای توصیف این فرایند ارائه شده است [17].

ایده اصلی روش‌هایی که پیش‌تر مطالعه کرده‌ایم، به‌کارگیری فازینگ هدایت‌ شده با استفاده از روش‌های مختلف هوش مصنوعی (Artificial Intelligence – AI)، مانند الگوریتم‌های ژنتیکی (Genetic Algorithms) و یادگیری تقویتی (Reinforcement Learning)، همراه با امکان ترکیب آن‌ها با اجرای نمادین برخط (Online Symbolic Execution) است تا در یک بازه زمانی محدود، بیشترین میزان پوشش کد (Code Coverage) ممکن برای برنامه‌های باینری تحت آزمون (Binary Programs Under Test) به دست آید.

در این سطح، فرایند فازینگ برای یک گره v با تولید مقادیر مختلف Buf f erin(v) عمل می‌کند که به ابعاد (Dimensions) و مشخصات دیکشنری داده (Data Dictionary Specification) تعیین‌ شده توسط کاربر محدود می‌باشند. نقطه ضعف این روش آن است که ممکن است ورودی‌هایی تولید کند که به دلیل وابستگی‌های گره (Node Dependencies) در گراف متصل‌کننده سامانه، در یک جریان (Flow) با شرایط عادی قابل تولید نباشند. با این‌ حال، مسائل شناسایی ‌شده (Detected Issues) همچنان می‌توانند ارزشمند باشند، زیرا می‌توان از آن‌ها در زمان دیگری یا در معماری متفاوتی از سامانه استفاده کرد.

۴.۲ فازینگ معماری گراف مستقر شده (Fuzzing the Deployed Graph Architecture)

سه عملیات (Operations) وجود دارد که می‌توان از آن‌ها برای انجام فازینگ برنامه کاربردی مستقر شده در سطح گراف (Graph Level) استفاده کرد که احتمال وقوع (Probability) هر یک از آن‌ها را می‌توان توسط کاربر تنظیم کرد:

افزودن یا حذف یال‌های اختیاری (Optional Edges) از گراف فعلی، با احتمال P_edge.
جایگزین‌کردن گره‌های اختیاری موجود (Existing Optional Nodes) با گره‌های دیگری که کاملاً با همان رابط (Interface) سازگار هستند، با احتمال P_rep.

ایده فازینگ گراف آن است که اتصالات متقابل (Interconnections) ممکن میان گره‌ها و پروتکل‌های ارتباطی (Communication Protocols) آن‌ها را شبیه‌سازی کند تا مسائلی شناسایی شوند که ممکن است تنها زمانی ظاهر شوند که گره‌ها (و فرایندهای (Processes) مستقر شده بر روی آن‌ها) با یکدیگر ارتباط برقرار می‌کنند.

راهکارهای دیگری که پیش‌تر فازینگ پروتکل (Protocol Fuzz Testing) را پیاده‌سازی کرده‌اند نیز می‌توانند مورد استفاده قرار گیرند. یکی از این نمونه‌ها AFLNet است؛ یک فازر جعبه ‌خاکستری (Grey Box Fuzzer) برای پروتکل‌های شبکه (Network Protocols). هنگامی که یک سامانه با AFLNet مورد آزمون قرار می‌گیرد، خروجی دریافت‌شده (Received Output) برای ساخت یک گراف حالت (State Graph) مورد استفاده قرار می‌گیرد که انواع پاسخ‌های پروتکل (Protocol Response Types) مربوط به سامانه تحت آزمون (System Under Test – SUT) را توصیف می‌کند. AFLNet به‌ صورت آماده (Out of the Box) می‌تواند آسیب‌پذیری‌های موجود در پروتکل پیاده‌سازی‌شده دستگاه را شناسایی کند؛ اما علاوه بر آن، برای هر یک از انواع پاسخ حاصل ‌شده، برخی خروجی‌ها می‌توانند به دستگاه متصل در سامانه اینترنت اشیا (IoT System) ارسال شوند و در نتیجه، گستره (Breadth) موارد آزمون (Test Cases) افزایش یابد [9].

این ابزار به‌صورت آماده (Out of the Box) می‌تواند آسیب‌پذیری‌های موجود در پروتکل پیاده‌سازی‌شده دستگاه را شناسایی کند؛ همچنین، برای هر یک از انواع پاسخ حاصل‌شده، برخی خروجی‌ها می‌توانند به دستگاه متصل در سامانه اینترنت اشیا (IoT System) ارسال شوند و در نتیجه، گستره موارد آزمون (Breadth of Test Cases) افزایش یابد [9].

۴.۳ بهره‌گیری از اجرای کانکولیک و سازوکارهای هدایت ‌شده مبتنی بر هوش مصنوعی برای آزمون (Leveraging concolic execution and AI guided mechanisms for testing)

بر اساس چارچوب River، RiverIoT فرایند فازینگ (Fuzzing) را با استفاده از اجرای کانکولیک(Concolic Execution) به‌ صورت برخط (Online) پیاده‌سازی می‌کند [17]. پیاده‌سازی فعلی، فرایند فازینگ را از گره‌هایی که به‌عنوان ورودی (Input) علامت‌گذاری شده‌اند آغاز می‌کند؛ این گره‌ها، به‌طور کلی، حسگرها (Sensors) هستند؛ برای مثال، گره‌های S₀، S₁ و S₂ در شکل ۱ . سپس اجرای کانکولیک (Concolic Execution) را بر روی فرایندهای مستقر شده (Deployed Processes) در این گره‌ها اعمال می‌کند تا به‌صورت هدایت‌شده (Guided)، بیشترین تعداد ممکن از مسیرها (Paths) را طی کند؛ مسیرهایی که به‌صورت دنباله‌ای متناهی (Finite Sequence) از گره‌های متصل در شبکه تعریف می‌شوند.

بااین‌حال، محدودکردن مسیرهای این فرایندها می‌تواند به‌طور بالقوه موجب شود برخی از مسیرهای عمیق (Deep Paths) در گراف که هنوز مورد آزمون قرار نگرفته‌اند، نادیده باقی بمانند. برای پرداختن به این مسئله، دو روش وجود دارد که هر یک مزایا و معایب خاص خود را دارند:

۱) استفاده از اجرای کانکولیک (Concolic Execution) تنها در گره‌های آغازین (Starting Nodes) یا گره‌های ورودی (Input Nodes)، علامت‌گذاری نواحی بافر خروجی (Output Buffer Zones) مورد استفاده برای انشعاب (Branching) تنها توسط گره ورودی بعدی، و سپس فاز کردن (Fuzz) آن ناحیه خروجی با استفاده از یک الگوریتم ژنتیکی (Genetic Algorithm) مانند الگوریتمی که پیش‌تر در River پیاده‌سازی شده است [18]؛ یا صرفاً تغییر تصادفی (Random Modification) آن بر اساس فرهنگ داده (Data Dictionary) ارائه‌ شده.

این روش در واقع همان مفهوم دستیابی به بیشترین میزان ممکن پوشش حالت (State Coverage) در یک بازه زمانی محدود، در کنار پوشش کد (Code Coverage) است. اگرچه این روش ممکن است نتواند تمامی مسیرهای ممکن را در مجموعه‌ای از برنامه‌های به‌هم‌متصل (Interconnected Programs) کاوش کند، دست‌کم می‌تواند در شرایطی که منابع محدود هستند، یا زمانی که قطر (Diameter) گراف توصیف‌کننده برنامه کاربردی اینترنت اشیا (IoT Application) زیاد است، فازینگ و پوشش (Coverage) سریع را فراهم کند. قطر گراف به طول طولانی‌ترین مسیر کوتاه (Longest Shortest Path) در آن اشاره دارد.

۲) استفاده از اجرای کانکولیک (Concolic Execution) در هر گره و انتشار شرایط SMT (Z3) از یک گره به گره والدِ فراخواننده (Calling Parent). به‌ عنوان مثال، اتصال میان گره‌های S₀− > C− > O₀ را در نظر بگیرید و فرض کنید یک ورودی مشخص در S0 (که به ورودی C تبدیل می‌شود و بعداً می‌تواند بر خروجی O₀ تأثیر بگذارد) یک مسیر مشخص P را در O₀ تعیین می‌کند. به منظور افزایش پوشش کد (Code Coverage) با استفاده از اجرای کانکولیک (Concolic Execution)، یک الگوریتم باید در امتداد مجموعه مرتب‌ شده نقاط انشعاب (Branch Points) به ‌صورت B = B1, B2, …Bn درون مسیر P حرکت کند و ورودی‌هایی را پیدا کند که شرایط نقاط انشعاب را تغییر دهند. اما این ورودی به خروجی C و سپس به خروجی S0 وابسته است (شکل ۴).

یک مثال ساده و آموزشی در لیست زیر ارائه شده است. برای رسیدن به کد assert درون برنامه C، ورودی وارد شونده به Cباید در اندیس ۱ (Index 1) دارای مقدار ۴ باشد. این ورودی با خروجی به‌دست‌آمده درون برنامه S0 مطابقت دارد. برای به‌دست‌آوردن مقدار ۴ در آن موقعیت خاص، ورودی برنامه S0 باید در index 0 دارای مقدار ۲ باشد. صرفاً درخواست از یک حل‌کننده SMT (SMT Solver) برای حل اجتماع شرایط (Union of Conditions) کافی نیست، زیرا ابتدا باید برنامه S0 به‌گونه‌ای هدایت شود که وارد شاخه‌هایی گردد که خروجی را در محدوده موردنظر تغییر می‌دهند.

نمی‌توان به BufferOutput برچسب آلودگی (Taint) زد، زیرا این بافر عملاً یک ورودی (Input) نیست و نمی‌توان آن را مستقل از BufferInput تغییر داد. راه‌حل این مسئله آن است که اجرای کانکولیک (Concolic Execution) را طبق روال معمول بر روی S₀ انجام دهیم، شاخه‌هایی را که باعث تغییر محدوده حافظه (Memory Range) اشغال ‌شده توسط BufferOutput می‌شوند، رصد کنیم و سپس در پایان، از حل‌کننده SMT (در مورد ما Z3) بپرسیم که آیا راه‌حلی وجود دارد که شرایط شاخه فعلی به ‌دست‌آمده را به ‌همراه شرط موردنیاز برای C برآورده کند یا خیر.

لیست ۳. درون برنامه S_0:

				
					{
	a = BufferInput[0]
	b = a + 1
	if (b == 3)
	{
		BufferOutput[1] = 4;
	}
}

لیست ۴. درون برنامه C:

				
					{
	if (BufferInput[1] == 4)
	{
		assert
	}
}

این روش در عمل امکان‌پذیر است، اما در گراف‌هایی با قطر (Diameter) زیاد، دارای معایبی است؛ زیرا تعداد شرایط SMT موردنیاز برای تولید ورودی‌ها/خروجی‌های مطلوب می‌تواند به‌صورت نمایی (Exponentially) افزایش یابد. با این ‌حال، اگر منابع فیزیکی و زمانی (Physical and Time Resources) کافی در دسترس باشند، این روش معمولاً باید آزمون جامع‌تر و کامل‌تری (Exhaustive Testing) ارائه دهد. با فراهم بودن زیرساخت اجرای کانکولیک (Concolic Execution)، می‌توان از روش‌های مختلف مبتنی بر هوش مصنوعی (AI) برای هدایت بیشتر فرایند آزمون به سمت دستیابی به نتایج بهتر از نظر پوشش کد (Code Coverage) و پوشش حالت (State Coverage) استفاده کرد.

این روش‌ها، همان‌گونه که در [19]، [20]، [20] و [21] تعریف شده‌اند و پیش‌تر در بستر River ما پیاده‌سازی شده‌اند، از تکنیک‌هایی مانند الگوریتم‌های ژنتیکی (Genetic Algorithms)، شبکه‌های عصبی عمیق (Deep Neural Networks) یا یادگیری تقویتی (Reinforcement Learning) استفاده می‌کنند.

شکل ۳. تصویری که نشان می‌دهد چگونه جریان ارتباطی (Communication Flow) اولیه در داخل برنامه کاربر (سمت چپ) تغییر می‌یابد تا امکان اجرای کانکولیک (concolic execution) در چارچوب RiverIoT (سمت راست) فراهم شود؛ این فرآیند با آزمودن قابلیت‌های پروتکل‌های ارتباطی (Communication Protocols) نیز همراه است.

با فراهم بودن زیرساخت اجرای کانکولیک (Concolic Execution)، می‌توان از روش‌های مختلف مبتنی بر هوش مصنوعی (AI) برای هدایت بیشتر فرایند آزمون به سمت دستیابی به نتایج بهتر از نظر پوشش کد (Code Coverage) و پوشش حالت (State Coverage) استفاده کرد. این روش‌ها، همان‌گونه که در [19]، [20]، [20] و [21] تعریف شده‌اند و پیش‌تر در بستر River ما پیاده‌سازی شده‌اند، از تکنیک‌هایی مانند الگوریتم‌های ژنتیک (Genetic Algorithms)، شبکه‌های عصبی عمیق (Deep Neural Networks) یا یادگیری تقویتی (Reinforcement Learning) استفاده می‌کنند.

۴.۴ جزئیات پیاده‌سازی و شبیه‌سازی (Implementation and Simulation Details)

با در نظر گرفتن محدودیت‌های فرایندهایی که در برنامه‌های کاربردی اینترنت اشیا (IoT Applications) بر روی سخت‌افزارهای اختصاصی (Dedicated Hardware) اجرا می‌شوند، پیشنهاد پیاده‌سازی ما مسئولیت انجام تحلیل آلودگی (Taint Analysis) و حل قیود اجرای نمادین (Symbolic Execution Constraint Solving) را به مؤلفه‌ای (Component) درون چارچوب منتقل می‌کند. در نتیجه، مسئولیت هر گره صرفاً به اجرای ورودی ارائه‌ شده و بازگرداندن ردپای اجرا (Execution Trace) محدود می‌شود؛ ردپایی که توسط چارچوب تحلیل می‌شود. این فرایند در شکل ۳ نشان داده شده است. همچنین، ارتباط میان دستگاه‌ها دیگر به‌صورت مستقیم انجام نمی‌شود، بلکه با استفاده از همان مؤلفه درون چارچوب شبیه‌سازی (Simulate) می‌شود تا اطمینان حاصل شود که مسائل مربوط به پروتکل‌های ارتباطی (Communication Protocols) نیز قابل آزمون می‌باشند. به منظور اجرای فرایندها بر روی دستگاه‌های نهفته (Embedded Devices)، برنامه‌های بعدی ما استفاده از سازوکارهای توصیف‌شده در [13] و [12] است.

۵. نتیجه‌گیری و کارهای آینده (CONCLUSION AND FUTURE WORK)

این مقاله یک چارچوب یکپارچه آزمون (Integrated Testing Framework) پیشنهاد می‌کند که از معماری تعریف ‌شده توسط کاربر برای شبکه اینترنت اشیا (IoT Network) بهره می‌گیرد. با استفاده از مشخصات ارائه ‌شده در مثال، آزمون فازینگ (Fuzz Testing) را می‌توان نه‌تنها بر روی یک دستگاه، بلکه بر روی بخشی از شبکه یا حتی کل شبکه اعمال کرد و بدین ترتیب، امکان شناسایی آسیب‌پذیری‌هایی فراهم می‌شود که تنها زمانی خود را نشان می‌دهند که کل سامانه مورد آزمون قرار گیرد.

مشخصات پیشنهادی توسط یک سامانه آزمون (Testing System) خوانده می‌شود که نمونه‌های فازینگ (Fuzzing Instances) و دستگاه‌های تحت آزمون (Devices Under Test) را هماهنگ و مدیریت می‌کند. از آنجا که محیط دستگاه‌های اینترنت اشیا (IoT Devices) ناهمگون (Heterogeneous) است، اهمیت دارد که چنین مشخصاتی تا حد امکان وابستگی کمی به معماری سامانه تحت آزمون (System Under Test – SUT) داشته باشند و برای آزمونگر (Tester) جهت راه‌اندازی و اجرای موارد آزمون (Test Cases) خود، به حداقل تلاش نیاز داشته باشند.

به منظور جداسازی وابستگی‌های سامانه (System Dependencies)، می‌بایست یک رابط (Interface) مناسب و یک لایه میانی (Intermediate Layer) فراهم شود. در نتیجه، قابلیت توسعه‌پذیری (Extensibility) برای پذیرش طیف متنوعی از سامانه‌ها (Systems) قابل دستیابی خواهد بود [22]. هدف از مشخصات پیشنهادی، ایجاد واسطی نه تنها میان دستگاه‌های مختلف، بلکه میان این دستگاه‌ها و نرم‌افزار آزمون (Testing Software) است.

بااین‌حال، برای ارزیابی مناسب روش‌های ارائه‌شده و مصالحه‌های (Tradeoffs) میان آن‌ها، برنامه در دست اجرای (Work-in-Progress Plan) ما این است که با همکاری نزدیک با صنعت، یک مجموعه‌داده (Dataset) از نمونه‌های ساده و آموزشی ایجاد کنیم تا الگوهای رایج برنامه‌های کاربردی اینترنت اشیا (IoT Applications)، اندازه مسائل (Problem Sizes) و داده‌های ورودی/خروجی (Input/Output Data) معمول در این برنامه‌ها را به دست آوریم.

منابع

				
					[1] F. Bonomi, R. Milito, P. Natarajan, and J. Zhu, “Fog computing: A platform for internet of things and analytics,” in Big data and internet of things: A roadmap for smart environments. Springer, 2014, pp. 169–186.
[2] S. Basu and E. G. Sirer, “Trustless iot: A logic-driven architecture for iot hubs,” in 3rd {USENIX} Workshop on Hot Topics in Edge Computing (HotEdge 20), 2020.
[3] Y. Zheng, A. Davanian, H. Yin, C. Song, H. Zhu, and L. Sun, “Firm-afl: high-throughput greybox fuzzing of iot firmware via augmented process emulation,” in 28th {USENIX} Security Symposium ({USENIX} Security 19), 2019, pp. 1099–1114.
[4] V. Pham, M. Boehme, A. E. Santosa, A. R. Caciulescu, and A. Roychoudhury, “Smart greybox fuzzing,” IEEE Transactions on Software Engineering, pp. 1–1, 2019.
[5] J. Wang, B. Chen, L. Wei, and Y. Liu, “Superion: Grammar-aware greybox fuzzing,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 724–735.
[6] W. Yu, F. Liang, X. He, W. G. Hatcher, C. Lu, J. Lin, and X. Yang, “A survey on the edge computing for the internet of things,” IEEE access, vol. 6, pp. 6900–6919, 2017.
[7] M. M. Hossain, M. Fotouhi, and R. Hasan, “Towards an analysis of security issues, challenges, and open problems in the internet of things,” in 2015 ieee world congress on services. IEEE, 2015, pp. 21–28.
[8] J. Chen, W. Diao, Q. Zhao, C. Zuo, Z. Lin, X. Wang, W. C. Lau, M. Sun, R. Yang, and K. Zhang, “Iotfuzzer: Discovering memory corruptions in iot through app-based fuzzing.” in NDSS, 2018.
[9] V.-T. Pham, M. B¨ohme, and A. Roychoudhury, “Aflnet: a greybox fuzzer for network protocols,” in 2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST). IEEE, 2020, pp. 460–465.
[10] J. Wang, B. Chen, L. Wei, and Y. Liu, “Skyfire: Data-driven seed generation for fuzzing,” in 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 2017, pp. 579–594.
[11] R. Gopinath and A. Zeller, “Building fast fuzzers,” arXiv preprint arXiv:1911.07707, 2019.
[12] B. Feng, A. Mera, and L. Lu, “P2im: Scalable and hardware-independent firmware testing via automatic peripheral interface modeling,” in 29th {USENIX} Security Symposium ({USENIX} Security 20), 2020, pp. 1237–1254.
[13] A. A. Clements, E. Gustafson, T. Scharnowski, P. Grosen, D. Fritz, C. Kruegel, G. Vigna, S. Bagchi, and M. Payer, “Halucinator: Firmware re-hosting through abstraction layer emulation,” in 29th {USENIX} Security Symposium ({USENIX} Security 20), 2020, pp. 1201–1218.
[14] MIPIAlliance, “Mipi white paper: Enabling the iot opportunity,” MIPIAlliance, Tech. Rep., September 2020. [Online]. Available:https://mipi.org/mipi-white-paper-enabling-IoT#specifications 
[15] O. Organization, “Profile m – release candidate,” ONVIF Organization, Tech. Rep., September 2020. [Online]. Available: https://www.onvif.org/profiles/profile-m/
[16] Z. Baba-Cheikh, G. El-Boussaidi, J. Gascon-Samson, H. Mili, and Y.-G. Gu´eh´eneuc, “A preliminary study of open-source iot development frameworks,” in Proceedings of the IEEE/ACM 42nd International Conference on Software Engineering Workshops, 2020, pp. 679–686.
[17] B. Ghimis, M. Paduraru, and A. Stefanescu, “River 2.0: an open-source testing framework using ai techniques,” in Proceedings of the 1st ACM SIGSOFT International Workshop on Languages and Tools for Next-Generation Testing, 2020, pp. 13–18.
[18] C. Paduraru, M.-C. Melemciuc, and A. Stefanescu, “A distributed implementation using apache spark of a genetic algorithm applied to test data generation,” in Proceedings of the Genetic and Evolutionary Computation Conference Companion, 2017, pp. 1857–1863.
[19] C. Paduraru, M.-C. Melemciuc, and M. Paduraru, “Automatic test data generation for a given set of applications using recurrent neural networks,” in Software Technologies, M. van Sinderen and L. A. Maciaszek, Eds. Cham: Springer International Publishing, 2019, pp. 307–326.
[20] C. Paduraru. and M. Melemciuc., “An automatic test data generation tool using machine learning,” in Proceedings of the 13th International Conference on Software Technologies - Volume 1: ICSOFT, INSTICC. SciTePress, 2018, pp. 472–481.
[21] C. Paduraru, M. Paduraru, and A. Stefanescu, “Optimizing decision making in concolic execution using reinforcement learning,” in 2020 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW), 2020, pp. 52–61.
[22] Z.-K. Zhang, M. C. Y. Cho, C.-W. Wang, C.-W. Hsu, C.-K. Chen, and S. Shieh, “Iot security: ongoing challenges and research opportunities,” in 2014 IEEE 7th international conference on service-oriented computing and applications. IEEE, 2014, pp. 230–234.

RiverIoT – ارائه یک چارچوب پیشنهادی برای فازینگ برنامه‌های کاربردی اینترنت اشیا

RiverIoT - a Framework Proposal for Fuzzing IoT Applications