شما در حال انجام IoT RNG هستید (تولید اعداد تصادفی در اینترنت اشیا)

در امنیت اینترنت اشیاء (IoT ) یک شکاف (crack) وجود دارد که بر 35 میلیارد دستگاه در سراسر جهان تأثیر می گذارد. اساساً، هر دستگاه اینترنت اشیا با مولد اعداد تصادفی سخت افزاری ( RNG) دارای یک آسیب پذیری جدی است که به موجب آن نمی تواند به درستی اعداد تصادفی تولید کند، که امنیت هرگونه استفاده بالادستی را تضعیف می کند.

برای انجام بیشتر عملیات مرتبط با امنیت، رایانه ها باید از طریق RNG مقادیر تصادفی و مخفی را تولید کنند. این مقادیر سپس اساس رمزنگاری، کنترل دسترسی، احراز هویت و موارد دیگر را تشکیل می دهند. جزئیات نحوه و چگونگی ایجاد این مقادیر برای هر بار استفاده متفاوت است، اما مثال متعارف در حال تولید کلید رمزگذاری است:

شکل 1: آلیس و باب سعی می کنند با استفاده از RNG مکالمه خصوصی داشته باشند

 

برای اینکه آلیس و باب به دور از چشمان کنجکاو حوا به صورت مخفیانه ارتباط برقرار کنند، باید با استفاده از RNG یک راز مشترک تولید کنند. این واقعیت که حوا این شماره را نمی داند تنها چیزی است که او را از به خطر انداختن محرمانه بودن ارتباطات باز می دارد. همین داستان برای جنبه های دیگر امنیت نیز مفید است: چه در کلیدهای SSH برای احراز هویت و چه در مقادیر تصادفی جلسه برای مجوز، اعداد تصادفی یکی از پایه های اصلی امنیت کامپیوتر است.

اما به نظر می رسد که این اعداد انتخاب شده “به طور تصادفی” همیشه در مورد دستگاه های IoT تصادفی نیستند. در حقیقت، در بسیاری از موارد، دستگاه ها کلیدهای رمزگذاری 0 یا بدتر را انتخاب می کنند. این می تواند منجر به سقوط فاجعه بار امنیت برای هرگونه استفاده بالادستی شود.

از سال 2021، اکثر سیستم های IoT روی تراشه SoCs  دارای سخت افزار اختصاصی RNG هستند که دقیقاً برای حل این مشکل طراحی شده است. اما متأسفانه، به این سادگی نیست. نحوه استفاده از وسایل جانبی بسیار مهم است و لبه دانش در اینترنت اشیا فقط به درستی می تواند به عنوان “انجام آن اشتباه” توصیف شود.

تماس نادرست با RNG سخت افزار

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

هنگامی که یک دستگاه اینترنت اشیا به یک عدد تصادفی نیاز دارد، از طریق SDK دستگاه یا به طور فزاینده ای از طریق سیستم عامل اینترنت اشیا با RNG سخت افزاری اختصاصی تماس می گیرد. البته آنچه فراخوانی تابع نامیده می شود متفاوت است، اما در لایه انتزاعی سخت افزار HAL  صورت می گیرد. این یک API است که توسط سازنده دستگاه ایجاد شده است و به گونه ای طراحی شده است که بتوانید به راحتی از طریق کد C با سخت افزار ارتباط برقرار کنید و نیازی به تنظیم و بررسی رجیسترهای خاص منحصر به فرد دستگاه نداشته باشید. عملکرد HAL چیزی شبیه به این است:

               u8 hal_get_random_number(u32 *out_number);

ما به دو بخش توجه داریم:

• یک پارامتر خروجی به نام out_number . اینجاست که تابع عدد تصادفی را قرار می دهد. این نشانگر یک عدد صحیح 32 بیتی بدون علامت است.
• مقدار بازگشتی برای مشخص کردن موارد خطا. بسته به دستگاه، ممکن است بولی یا تعدادی از شرایط خطای شمارش شده باشد.

بنابراین، اولین سوالی که ممکن است بپرسید این است: “چند نفر در طبیعت این کد خطا را بررسی می کنند؟” متأسفانه، پاسخ تقریباً هیچ کس است.

به عنوان مثال، فقط به نتایج GitHub برای استفاده از عملکرد MediaTek 7697 SoC HAL نگاه کنید:

یا حتی لایه انتزاعی FreeRTOS یک سیستم عامل محبوب IoT

https://github.com/search?q=HAL_RNG_GenerateRandomNumber&type=code

بدترین چیزی که می تواند اتفاق بیفتد چیست؟

دستگاه ها کد خطای عملکرد RNG HAL را بررسی نمی کنند. اما واقعا چقدر مخرب است؟ این بستگی به دستگاه خاص دارد، اما به طور بالقوه بد است. خیلی بد. بیایید نگاهی بیندازیم.

عملکرد HAL در محیط جانبی RNG می تواند به دلایل مختلف شکست بخورد، اما متداول ترین (و قابل استفاده) این است که آنتروپی دستگاه تمام شده است. تجهیزات جانبی RNG سخت افزاری، آنتروپی را از طرق مختلف (مانند سنسورهای آنالوگ یا قرائت EMF  از جهان خارج می کنند، اما منبع بی نهایت ندارند. آنها فقط قادر به تولید تعداد زیادی بیت تصادفی در ثانیه هستند. اگر سعی کنید تابع RNG HAL را هنگامی که هیچ شماره تصادفی در اختیار شما نیست فراخوانی کنید، شکست می خورد و یک کد خطا باز می گرداند. بنابراین، اگر دستگاه سعی کند اعداد تصادفی زیادی را به سرعت دریافت کند، تماس ها شروع به شکست می کنند.

اما این مسئله در مورد اعداد تصادفی است؛ فقط داشتن یکی کافی نیست هنگامی که یک دستگاه نیاز به ایجاد یک کلید خصوصی جدید 2048 بیتی دارد، به عنوان مثال، عملکرد RNG HAL را بارها و بارها در یک حلقه فراخوانی می کند. این امر به طور جدی از توانایی سخت افزاری برای حفظ وضعیت مالیات می گیرد و در عمل، اغلب نمی توانند. چند تماس اول ممکن است موفقیت آمیز باشد، اما معمولاً به سرعت باعث ایجاد خطا می شود.

بنابراین … عملکرد HAL در واقع برای یک عدد تصادفی هنگامی که از کار می افتد به شما چه می دهد؟ بسته به سخت افزار، یکی از موارد زیر است:

• آنتروپی جزئی
• عدد 0
• حافظه غیر اولیه

تصویر 2: این نباید وجود داشته باشد.

هیچکدام از آنها حافظه بسیار خوبی ندارند، اما حافظه اولیه چطور؟! چگونه این اتفاق می افتد؟ خوب، به یاد داشته باشید که عدد تصادفی یک اشاره گر خروجی است. سپس شبه کد زیر را در نظر بگیرید (که در صورت تمایل می توانید نمونه های زیادی از آن را در GitHub بیابید):

u32 random_number;

hal_get_random_number(&random_number);

// Sends over the network

packet_send(random_number);

متغیر random_number اعلان می شود و روی پشته است اما هرگز مقداردهی نمی شود. اگر تابع HAL به گونه ای رفتار کند که هرگز متغیر خروجی را در صورت بروز خطا (که رفتار متداول است) رونویسی نکند، آنگاه مقدار متغیر شامل RAM اولیه نشده است که سپس از طریق شبکه برای شخص دیگری ارسال می کنیم.

این‌ها سناریوهای ساختگی یا غیرواقعی نیستند. دستگاه ها در حال حاضر از کلیدهای رمزنگاری 0 یا بدتر استفاده می کنند.

با تجزیه و تحلیل Keyfactor در سال 2019 از گواهینامه های RSA در دسترس عموم مشخص شد که از هر 172 گواهینامه 1 مورد در برابر حملات شناخته شده آسیب پذیر است. نویسندگان به ایجاد اعداد تصادفی در دستگاه های IoT به عنوان یکی از جرایم اشاره کردند، اما از شناسایی علت دقیق آن کوتاهی کردند. در حالی که نمی توان با اطمینان گفت که تحقیقات ما مسئول این نتایج است … موارد گسترده کلیدهای RSA ضعیف در دستگاه های IoT دقیقاً همان چیزی است که انتظار می رود.

مطمئناً به نظر می رسد که این یک مسئله مقیاس بزرگ در عمل است، نه فقط در تئوری.

کاربر را سرزنش نکنید

به راحتی می توانید وضعیت موجود را بررسی کرده و نتیجه بگیرید که این فقط خطای کاربر است، اما اینطور نیست. کاربران در وضعیت بدون برد قرار گرفته اند. می بینید، اعداد تصادفی در مواقع ضروری بسیار مهم هستند. غالباً نمی توانید خطا را به شکلی ظریف “مدیریت” کرده و به جلو حرکت کنید.

به عنوان مثال، مستندات MediaTek شامل کد نمونه زیر برای توسعه دهندگان MT7697 SoC است:

if(HAL_TRNG_STATUS_OK != hal_trng_get_generated_random_number(&random_number)) {

    //error handle

}

اما اگر شما مجموعه شبکه ای هستید که در حین تولید یک رمز برای ارتباطات ایمن هستید، چگونه باید خطا را “مدیریت” کنید؟ در واقع فقط دو گزینه وجود دارد:

• لغو کنید، کل فرایند را از بین ببرید.
• حلقه را روی عملکرد HAL به مدت نامحدود تا زمان تکمیل تماس بچرخانید، تمام فرآیندهای دیگر را مسدود کرده و از 100٪ CPU در این فرآیند استفاده کنید.

هیچ کدام راه حل قابل قبولی نیستند. به همین دلیل است که توسعه دهندگان شرایط خطا را نادیده می گیرند – گزینه های جایگزین وحشتناک هستند و اکوسیستم اطراف سخت افزار RNG هیچ لطفی به آنها نکرده است.

حتی وقتی توسعه دهندگان از مزیت وقت خود در کنار خود برخوردار باشند، اوضاع خیلی بهتر نیست. برخی از دستگاهها، مانند STM32، دارای اسناد و مدارک قابل ملاحظه ای هستند و حتی شواهدی از تصویری سفید بودن توسط فروشنده ارائه شده است، اما این‌ها یک استثنا هستند. تعداد کمی از دستگاه‌ها حتی توضیحی اساسی در مورد نحوه عملکرد سخت افزار RNG دارند و تعداد کمی از آنها هنوز هیچ گونه اسناد و مدارکی در مورد موارد اولیه مانند سرعت مورد انتظار، محدوده دمای کارکرد ایمن و شواهد آماری تصادفی ندارند.

به طور غیرحرفه ای، ما سعی کردیم اسناد STM32 را با دقت دنبال کنیم و همچنان موفق به ایجاد کدی شدیم که به اشتباه پاسخ های خطا را مدیریت می کرد. تلاش های متعدد و کد قابل توجهی لازم بود تا تماس های اضافی به RNG مسدود شود و در صورت وجود پاسخ خطا به درستی چرخش شود – و حتی در آن صورت، نتایج مشکوکی را مشاهده کردیم که باعث شد در کد خود شک کنیم. جای تعجب نیست که توسعه دهندگان IoT RNG، اشتباه انجام می دهند، اما بیشتر در مورد آن در زیر توضیح داده شده است.

زیر سیستم CSPRNG

بنابراین شاید برای شما این سوال پیش آمده باشد که “چه چیزی این ویژگی را منحصر به فرد در اینترنت اشیا می کند؟ آیا این مسئله روی لپ تاپ ها و سرورها نیز تأثیر می گذارد؟ ” پاسخ این است که این یک مشکل منحصر به فرد برای دنیای اینترنت اشیا است زیرا این نوع مدیریت سطح پایین دستگاهها معمولاً توسط سیستم عاملی انجام می شود که به طور قابل توجهی در دستگاه های IoT معمولی وجود ندارد.

شکل 3: اجزای زیرسیستم CSPRNG

 

هنگامی که یک برنامه به یک شماره تصادفی امن رمزنگاری شده در سرور لینوکس نیاز دارد، از RNG سخت افزاری به طور مستقیم نمی خواند یا با برخی از توابع HAL تماس نمی گیرد و با کدهای خطا مبارزه می کند. نه، فقط از /dev /urandom می خواند. این یک زیرسیستم تولیدکننده اعداد شبه تصادفی امن CSPRNG) ) است که به عنوان API در اختیار برنامه های کاربردی قرار گرفته است. در هر سیستم عامل اصلی نیز زیر سیستم های مشابهی وجود دارد: Windows، iOS، MacOS، Android، BSD.

نکته مهم این است که تماس با /dev /urandom هرگز شکست نمی خورد و هرگز اجرای برنامه را مسدود نمی کند. زیر سیستم CSPRNG می تواند بلافاصله دنباله ای بی پایان از اعداد تصادفی قوی تولید کند. با این کار مشکل توابع HAL که اجرای برنامه را مسدود می کنند یا با شکست مواجه می شوند حل می کند.

یکی دیگر از ویژگی‌های مهم طراحی زیر سیستم CSPRNG، استخر آنتروپی است. این برای جذب آنتروپی از منابع مختلف، از جمله RNG های سخت افزاری (HWRNGs)  طراحی شده است. با توجه به جادوی عملیات xor، همه این منابع ضعیف آنتروپی به صورت جداگانه می توانند در یک منبع قوی ترکیب شوند. حوضچه آنتروپی همچنین هر گونه نقطه خرابی را در بین منابع آنتروپی حذف می کند: برای شکستن RNG، باید همه منابع آنتروپی را به طور همزمان پیش بینی کنید.

این روش صحیح برای تولید اعداد تصادفی امن رمزنگاری شده است و از قبل در همه جا استاندارد است … به جز اینترنت اشیا.

چرا واقعاً به یک زیر سیستم CSPRNG احتیاج دارید

طراحی کل زیر سیستم CSPRNG بسیار سخت به نظر می رسد، به ویژه هنگامی که ابزار شما از یکی از آن سیستم عامل های IoT جدید استفاده نمی کند. شاید کافی باشد فقط گلوله را بکشید و حلقه را بر روی عملکرد RNG HAL بچرخانید. به این ترتیب شما همیشه اعداد تصادفی خوبی دریافت می کنید، درست است؟

این بخش از این ایده که استفاده از RNG های سخت افزاری به تنهایی بی خطر است، نادیده گرفته شده است.

کد منبع آسیب پذیر

هیچ کس کد منبع را کاملاً از ابتدا نمی نویسد، به ویژه در دنیای دستگاه های اینترنت اشیا. همیشه تعدادی کد مرجع یا نمونه سند وجود دارد که توسعه دهندگان از آنها شروع می کنند. رابط با سخت افزار برای هر دستگاهی دشوار است، چه برسد به سخت افزاری مانند سخت افزار RNG جانبی.

وقتی کد منبع دستگاه دارای آسیب پذیری باشد، به هر دستگاهی که از آن استفاده می کند انتشار می یابد. پس از همه اینها، چگونه باید توسعه دهنده تفاوت بین یک مرجع آسیب پذیر و یک برنامه عجیب و غریب را بداند؟ در اینجا چند نمونه آورده شده است:

استفاده از HWRNG برای کاشت PRNG ناامن

PRNG هایی مانند libc rand ()  بسیار ناامن هستند زیرا اعدادی که تولید می کنند اطلاعاتی در مورد وضعیت داخلی RNG نشان می دهد. آنها برای زمینه های غیر مرتبط با امنیت مناسب هستند زیرا پیاده سازی آنها سریع و آسان است. اما استفاده از آنها برای مواردی مانند کلیدهای رمزگذاری منجر به سقوط فاجعه بار امنیت دستگاه می شود، زیرا همه اعداد قابل پیش بینی هستند.

متأسفانه، بسیاری از SDK ها و سیستم عامل هایی که از RNG های سخت افزاری پشتیبانی می کنند از PRNG ناامن استفاده می کنند. سیستم عامل Contiki-ng IoT برای Nrdic Semiconductor’s nrf52840 SoC دقیقاً این کار را با کاشتن عملکرد Libc rand ()  ناامن با سخت افزار RNG ::  انجام می دهد.

https://contiki-ng.readthedocs.io/en/release-v4.6/_api/arch_2cpu_2nrf52840_2dev_2random_8c_source.html

void

 random_init(unsigned short seed)

 {

   (void)seed;

   unsigned short hwrng = 0;

   NRF_RNG->TASKS_START = 1;

   NRF_RNG->EVENTS_VALRDY = 0;

   while(!NRF_RNG->EVENTS_VALRDY);

   hwrng = (NRF_RNG->VALUE & 0xFF);

   NRF_RNG->EVENTS_VALRDY = 0;

   while(!NRF_RNG->EVENTS_VALRDY);

   hwrng |= ((NRF_RNG->VALUE & 0xFF) << 8);

   NRF_RNG->TASKS_STOP = 1;

   srand(hwrng);

 }

Seeding libc rand() with the hardware RNG entropy: شکل 4

 

unsigned short

 random_rand(void)

 {

   return (unsigned short)rand();

 }

Future calls to random_rand() call the insecure libc rand() :شکل 5

 

به طور واضح، هیچ روش مطمئنی برای استفاده از libc rand () برای تولید مقادیر امن وجود ندارد. این واقعیت که مقدار تصادفی با استفاده از سخت افزار ایجاد می شود اهمیتی ندارد زیرا مهاجم می تواند آن را با استفاده از untwister استخراج یا شمارش کند. آنچه مهم است این است که وقتی کاربر random_rand () را صدا می کند، خروجی ناامن از تماس libc rand حاصل خواهد شد.

همچنین می توانید رفتار آسیب پذیر یکسانی را در کد MediaTek Arduino مشاهده کنید:

https://github.com/MediaTek-Labs/Arduino-Add-On-for-LinkIt-SDK/blob/53acd43fbee57b034141068969fa643465dfd743/project/linkit7697_hdk/apps/wifi_demo/src/sys_init.c#L198

/**

* @brief       This function is to get random seed.

* @param[in]   None.

* @return      None.

*/

static void _main_sys_random_init(void)

{

#if defined(HAL_TRNG_MODULE_ENABLED)

    uint32_t            seed;

    hal_trng_status_t   s;

    s = hal_trng_init();

    if (s == HAL_TRNG_STATUS_OK) {

        s = hal_trng_get_generated_random_number(&seed);

    }

    if (s == HAL_TRNG_STATUS_OK) {

        srand((unsigned int)seed);

    }

 Insecure libc rand() usage in MediaTek SDK :شکل 6

بنابراین حتی اگر دستگاه شما دارای سخت افزار RNG جانبی باشد و حتی اگر فکر می کنید از آن استفاده می کنید، ممکن است امن نباشید.

 

مزایای استفاده

گاهی اوقات، دستگاه ها به روشی بسیار عجیب و غریب کار می کنند که اصلاً واضح نیست. عدم رعایت صحیح این ویژگی ها می تواند منجر به سقوط فاجعه بار امنیت دستگاه شود. یکی از این موارد LPC 54628 است.

هنگام آزمایش LPC 54628، متوجه شدیم که از RNG سخت افزاری اعداد تصادفی با کیفیت بسیار نامناسب دریافت می کنیم-آنقدر بد که ما مشکوک هستیم که ممکن است در ابزار ما مشکلی وجود داشته باشد. معلوم شد حق با ما بود اگر دفترچه راهنمای کاربر را با دقت بخوانید، در صفحه 1،106 (از 1،152) ، به دستورالعمل های زیر توجه خواهید کرد:

“کیفیت تصادفی بودن (آنتروپی) اعداد تولید شده توسط مولد اعداد تصادفی به حالتهای اولیه منطق داخلی بستگی دارد. در صورت نیاز به یک عدد تصادفی 128 بیتی یا 256 بیتی، توصیه نمی شود چندین کلمه 32 بیتی را به یکدیگر متصل کنید. به عنوان مثال، اگر دو کلمه 128 بیتی به هم متصل شوند، RNG سخت افزاری 2 برابر 128 بیت آنتروپی را ارائه نمی دهد.

برای تشکیل یک عدد 128 بیتی، یک عدد تصادفی 32 بیتی خوانده می شود، سپس 32 عدد بعدی خوانده می شود اما استفاده نمی شود. عدد 32 بیت بعدی خوانده و استفاده می شود و غیره. بنابراین 32 عدد تصادفی 32 بیتی بین دو عدد 32 بیتی که استفاده می شود رد می شود.”

بنابراین برای اینکه بتوانید از RNG جانبی درست استفاده کنید، باید یک عدد تصادفی دریافت کنید و سپس 32 بعدی را کنار بگذارید. سپس این کار را به صورت حلقه ادامه دهید! در کد آزمایش، ما فقط تابع RNG HAL را فراخوانی کردیم و از نتایج استفاده کردیم … ، که روشی نسبتاً منطقی برای نوشتن کد است. چند نفر زحمت می کشند آن دفترچه راهنمای کاربر را بخوانند؟ یا حتی اگر آنها کد “صحیح” را که اعداد را دور انداخته است پیدا کردند، آیا آن را حذف می کنند زیرا غیر ضروری به نظر می رسد؟

واضح است که اتکا به چنین رفتاری برای امنیت غیرقابل قبول است. حتی اگر برخی از توسعه دهندگان برخی اوقات این کار را درست انجام دهند، داشتن این نوع API تضمین می کند که دستگاه های آسیب پذیر را با توجه به تعداد زیاد مخاطبان تولید می کند.

تحلیل آماری

بسیار خوب، بنابراین فرض کنید که مشکل حسابرسی کد دستگاه خود را پشت سر گذاشته اید تا مطمئن شوید که در واقع از RNG سخت افزاری استفاده می کند، و اطمینان حاصل کرده اید که شرایط خطا را بررسی کرده و تا زمان آماده شدن دستگاه بچرخید، و با زحمت آن را مطالعه کرده اید. دفترچه راهنمای کاربر 1000 صفحه ای دستگاه شما برای اطمینان از اینکه هرگونه مزاحمت را تشخیص داده اید…. مطمئناً شما باید ایمن باشید، درست است؟

به نظر می رسد که آنتروپی خام تجهیزات جانبی RNG سخت افزاری IoT از نظر کیفیت بسیار متفاوت است. اکثر دستگاه ها در آزمون های تجزیه و تحلیل آماری شکست می خورند، که در زیر خلاصه می کنیم. اما به خاطر داشته باشید که این نتایج اغلب می تواند به خود دستگاه بستگی داشته باشد، زیرا نقص های کوچک تولیدی حتی برای یک مدل و مدل یک دستگاه نتایج متفاوتی ایجاد می کند.

MediaTek 7697

یکی از مواردی که ما هنگام تجزیه و تحلیل آنتروپی برای آن آزمایش کردیم، توزیع نسبی بایت های تولید شده توسط RNG است. در یک دنیای کامل، باید انتظار داشته باشیم که هر بایت به یک اندازه محتمل باشد، بنابراین توزیع بایت ها باید یک خط مسطح باشد (البته Modulo هر گونه برآمدگی تصادفی جزئی). اما این چیزی نیست که ما برای MT7697 می بینیم:

شکل 7: هیستوگرام فراوانی هر بایت 0 تا 255 در مدیاتک 7697 SoC

نمودار بالا یک هیستوگرام است که فرکانس نسبی هر بایت ممکن (0 -> 255) را به صورت تجربی از RNG سخت افزاری MediaTek 7697 SoC اندازه گیری می کند. به آن الگوی دندان اره توجه کنید: این قطعاً “تصادفی نیست”. هیچ الگویی نباید وجود داشته باشد. چقدر از استفاده مستقیم از آن به عنوان کلید رمزنگاری خود احساس راحتی می کنید؟

Nordic Semiconductor nrf52840

RNG سخت افزاری Nrdic Semiconductor nrf52840 SoC یک الگوی 12 بیتی تکراری 0x000 را نشان می دهد که هر 0x50 بایت رخ می دهد:

Repeating 0x000 in the nrf52840 SoC :شکل 8

این واقعیت که این 12 بایت بود، و نه 8 یا 16، بسیار جالب بود. ما توضیحی عالی برای آن نداریم، اما احتمالاً به عملکرد داخلی سخت افزار RNG جعبه سیاه بستگی دارد.

STM32-L432KC

متأسفانه، ما نمودار خوبی برای نشان دادن این مورد نداریم، اما در اینجا نتایج حاصل از dieharder، یک ابزار آزمایش تصادفی آماری استاندارد صنعت، آمده است:

#=============================================================================#

#            dieharder version 3.31.1 Copyright 2003 Robert G. Brown          #

#=============================================================================#

          rng_name   |           filename             |rands/second|

  file_input_raw|STM32L432randData.4gb.32768trans.fullblocking.bin| 1.72e+07  |

#=============================================================================#

       test_name   |ntup| tsamples |psamples| p-value |Assessment

#=============================================================================#

rgb_minimum_distance|   0|     10000|   1000|0.00000000| FAILED

شکل 9: نمونه ای از نتایج تجزیه و تحلیل آماری dieharder برای STM32-L432KC SoC

 

همانطور که می بینید، این آزمایش در آزمون RGB Minimum Distance” ” (فاصله حداقل) شکست می خورد. این آزمایش این است که از RNG برای ترسیم تصادفی اعداد در یک شبکه بزرگ و سپس محاسبه کوچکترین فاصله بین هر دو نقطه استفاده می کند. این آزمون به ویژه در شناسایی همبستگی های ظریف بین اعداد، مانند تکرار، خوب است. شکست این آزمایش به احتمال زیاد نشان می دهد که اعداد تولید شده توسط RNG مستقل از یکدیگر نیستند یا به نحوی تکرار می شوند.

در حالی که بسیاری از RNG های سخت افزاری که آزمایش کردیم خوب به نظر می رسند، مانند   LPC54628 (با دور انداختن 32*32 بیتی) و ESP32، تنها نتیجه منطقی که می توان در اینجا گرفت این است که آنتروپی خام گرفته شده از RNG سخت افزاری نباید به طور جداگانه مورد اعتماد قرار گیرد. تجمع کلیدی و آنتروپی که زیر سیستم CSPRNG ارائه می دهد اساساً برای اجتناب از انجام IoT RNG ضروری است.

نتیجه گیری

یکی از بخش های سخت در مورد این آسیب پذیری این است که این یک مورد ساده نیست که به راحتی قابل وصله باشد. برای رفع این مشکل، یک ویژگی اساسی و پیچیده باید در دستگاه IoT مهندسی شود.

این امر بر کل صنعت اینترنت اشیا تأثیر می گذارد. آسیب پذیری اصلی در SDK یک دستگاه یا در اجرای SoC خاص نیست.

اینترنت اشیا به زیر سیستم CSPRNG نیاز دارد. فقط با تغییر اسناد و آموزش کاربران، این مشکل برطرف نمی شود. اولین مکان برای چنین زیر سیستم CSPRNG یکی از محبوب ترین سیستم عامل های اینترنت اشیا است. اگر در حال طراحی یک دستگاه جدید از ابتدا هستید، توصیه می کنیم CSPRNG را در یک سیستم عامل پیاده سازی کنید.

کدنویسی کد RNG برای نوشتن به تنهایی، مانند کد رمزنگاری، خطرناک تلقی می شود. مهم نیست چقدر با تجربه هستید، هرگز کد خود را برای رابط کاربری با سخت افزار RNG ننویسید. مطمئناً اشتباه خواهید کرد. در عوض باید از زیر سیستم CSPRNG استفاده کنید که توسط یک لایه انتزاعی پایین در دسترس قرار گرفته است.

هرگز از آنتروپی مستقیماً از سخت افزار RNG استفاده نکنید. در کل، RNG های سخت افزاری برای استفاده رمزنگاری (فوری) مناسب نیستند. آنتروپی ضعیف را می توان و باید از طریق نرم افزار، از طریق CSPRNG برطرف کرد.

در کوتاه مدت، آنچه شما می توانید انجام دهید این است:

مالکان دستگاه

به روزرسانی ها را زیر نظر داشته باشید و مطمئن شوید که در صورت موجود شدن آنها را اعمال کنید. این مشکلی است که با نرم افزار حل می شود، اما ممکن است مدتی طول بکشد. در عین حال، مراقب باشید که بیش از حد به ابزارهای اینترنت اشیاء خود اعتماد نکنید. برای دستگاه های خانگی که نیاز به اتصال به اینترنت دارند، آنها را در یک بخش شبکه اختصاصی قرار دهید که فقط می تواند از خارج به آن دسترسی پیدا کند. این به جلوگیری از هرگونه نقض از گسترش به بقیه شبکه شما کمک می کند.

توسعه دهندگان دستگاه IOT

در صورت امکان، دستگاههای اینترنت اشیا را انتخاب کنید که شامل CSPRNG API است که از منابع مختلف آنتروپی از جمله RNG های سخت افزاری تهیه شده است. اگر CSPRNG موجود نیست و چاره دیگری ندارید، هم کتابخانه هایی را که به آنها تکیه می کنید و هم کد خود را با دقت مرور کنید تا مطمئن شوید که با کدی که از حافظه غیر اولیه خوانده می شود کار نمی کنید که از ثبات های جانبی سخت افزاری RNG یا خطا چشم پوشی می کند. در صورت عدم وجود آنتروپی دیگر مسدود نمی شود. مفاهیم مربوط به موقعیت های زمان واقعی را که مسدود شدن یک گزینه مناسب نیست، با دقت در نظر بگیرید.

تولیدکنندگان دستگاه / سیستم های عملیاتی IOT

هرگونه استفاده مستقیم از عملکرد RNG HAL را در SDK خود منسوخ و یا غیرفعال کنید. در عوض، یک API CSPRNG که با استفاده از منابع آنتروپی قوی و متنوع با استفاده از RNG سخت افزاری مناسب استفاده می شود، قرار دهید. پیاده سازی /dev /urandom هسته لینوکس می تواند به عنوان یک مرجع عالی عمل کند.

 

bishopfox