/dev/random، یک تولید کننده اعداد شبه تصادفی رمزنگاری امن (CSPRNG)، شناخته شده است که یک مشکل آزاردهنده دارد: مسدود کردن. این مقاله توضیح می دهد که چگونه می توانید آن را حل کنید.
طی چند ماه گذشته، امکانات تولید اعداد تصادفی در هسته کمی دوباره کار شده است، اما مشکلات این زیرسیستم در طول دوره گسترده‌تر حل شده است. . بیشترین برای جلوگیری از مسدود شدن تماس سیستم getrandom() برای مدت طولانی هنگام بوت شدن سیستم ساخته شد، اما دلیل اصلی این امر رفتار مسدود کردن استخر تصادفی بود. یک پچ اخیر این استخر را حذف کرده و انتظار می رود که به سمت هسته اصلی حرکت کند.
اندی لوتومیرسکی نسخه سوم این پچ را در پایان دسامبر منتشر کرد. او کمک می کند "دو تغییر معنایی عمده در APIهای تصادفی لینوکس". پچ یک پرچم جدید GRND_INSECURE را به فراخوانی سیستم getrandom() اضافه می کند (البته Lutomirsky از آن به عنوان getentropy() یاد می کند که در glibc با استفاده از getrandom() با پرچم های ثابت پیاده سازی می شود). این پرچم باعث می‌شود که تماس همیشه مقدار داده‌های درخواستی را برمی‌گرداند، اما بدون تضمین تصادفی بودن داده‌ها. هسته به سادگی تمام تلاش خود را می کند تا بهترین داده های تصادفی را در زمان معین تولید کند. "احتمالا بهترین کار این است که آن را "ناامن" بنامیم (ناامن) برای جلوگیری از استفاده از این API برای مواردی که نیاز به امنیت دارند."
وصله ها همچنین حوضچه مسدود کننده را حذف می کنند. هسته در حال حاضر دارای دو مخزن داده تصادفی است که یکی مربوط به /dev/random و دیگری به /dev/urandom است، همانطور که در این توضیح داده شده است. 2015. استخر مسدود کننده استخری برای /dev/random است. خواندن برای آن دستگاه مسدود می شود (به معنی نام آن) تا زمانی که آنتروپی "کافی" از سیستم برای برآورده کردن درخواست جمع آوری شود. اگر آنتروپی کافی در استخر وجود نداشته باشد، خواندن بیشتر از این فایل نیز مسدود می شود.
حذف lock pool به این معنی است که خواندن از /dev/random مانند getrandom() با پرچم‌ها روی صفر عمل می‌کند (و پرچم GRND_RANDOM را به یک noop تبدیل می‌کند). هنگامی که تولید کننده اعداد تصادفی رمزنگاری (CRNG) مقداردهی اولیه شد، خواندن از /dev/random و فراخوانی به getrandom(...,0) مسدود نمی شود و مقدار درخواستی داده تصادفی را برمی گرداند.
لوتومیرسکی می گوید: من معتقدم که استخر مسدود کردن لینوکس منسوخ شده است. لینوکس CRNG خروجی ای تولید می کند که به اندازه کافی خوب است که حتی برای تولید کلید مورد استفاده قرار گیرد. استخر مسدود کننده به هیچ وجه قوی‌تر نیست و برای پشتیبانی از آن به زیرساخت‌های زیادی با ارزش مشکوک نیاز دارد.»
این تغییرات با هدف اطمینان از اینکه برنامه‌های موجود واقعاً تحت تأثیر قرار نخواهند گرفت انجام شد و در واقع مشکلات کمتری در انتظار طولانی‌مدت برای چیزهایی مانند تولید کلید GnuPG وجود داشت.
«این قسمت‌ها نباید برنامه‌های موجود را مختل کنند. /dev/urandom بدون تغییر باقی می ماند. /dev/random همچنان بلافاصله پس از راه‌اندازی مسدود می‌شود، اما کمتر از قبل مسدود می‌شود. getentropy() با پرچم‌های موجود نتیجه‌ای را برمی‌گرداند که برای اهداف عملی مانند قبل مناسب است."
لوتومیرسکی خاطرنشان کرد که هنوز یک سوال باز است که آیا هسته باید به اصطلاح "اعداد تصادفی واقعی" را ارائه دهد، که این همان کاری است که هسته مسدودکننده قرار بود تا حدی انجام دهد. او تنها یک دلیل برای این امر می‌بیند: «تطابق با استانداردهای دولتی». لوتومیرسکی پیشنهاد کرد که اگر هسته این کار را ارائه می‌دهد، باید از طریق یک رابط کاملاً متفاوت انجام شود، یا باید به فضای کاربر منتقل شود و به کاربر اجازه می‌دهد نمونه‌های رویداد خام را بازیابی کند که می‌تواند برای ایجاد چنین استخر قفل استفاده شود.
استفان مولر این مجموعه را پیشنهاد کرد برای Linux Random Number Generator (LRNG) (در حال حاضر نسخه 26 منتشر شده است) می تواند راهی برای ارائه اعداد تصادفی واقعی برای برنامه هایی باشد که به آن نیاز دارند. LRNG «کاملاً با دستورالعمل‌های SP800-90B در مورد منابع آنتروپی مورد استفاده برای تولید بیت‌های تصادفی مطابقت دارد» و آن را راه‌حلی برای مشکل استانداردهای دولتی می‌سازد.
متیو گرت به اصطلاح «داده‌های تصادفی واقعی» اعتراض کرد و خاطرنشان کرد که دستگاه‌های نمونه‌برداری شده در اصل می‌توانند به اندازه کافی دقیق مدل‌سازی شوند تا قابل پیش‌بینی باشند: «ما در اینجا از رویدادهای کوانتومی نمونه‌برداری نمی‌کنیم».
مولر پاسخ داد که این اصطلاح از استاندارد آلمانی AIS 31 برای توصیف یک مولد اعداد تصادفی آمده است که فقط یک نتیجه را تولید می کند "با همان سرعتی که منبع نویز زیربنایی آنتروپی تولید می کند."
جدای از تفاوت‌های اصطلاحی، داشتن یک استخر قفل که توسط وصله‌های LRNG پیشنهاد می‌شود به سادگی منجر به مشکلات مختلفی می‌شود، حداقل اگر بدون دسترسی به آن دسترسی داشته باشید.
همانطور که لوتومیرسکی گفت: "این مشکل را حل نمی کند. اگر دو کاربر مختلف برنامه های احمقانه ای مانند gnupg را اجرا کنند، فقط یکدیگر را تخلیه می کنند. من می بینم که در حال حاضر دو مشکل اصلی با /dev/random وجود دارد: مستعد DoS (به عنوان مثال کاهش منابع، نفوذ مخرب یا چیزی مشابه) است، و از آنجایی که برای استفاده از آن به هیچ امتیازی نیاز نیست، همچنین مستعد سوء استفاده است. Gnupg اشتباه است، این یک فروپاشی کامل است. اگر یک رابط غیرمجاز جدید اضافه کنیم که gnupg و برنامه‌های مشابه از آن استفاده می‌کنند، دوباره ضرر می‌کنیم."
مولر خاطرنشان کرد که افزودن getrandom() اکنون به GnuPG اجازه می‌دهد از این رابط استفاده کند، زیرا تضمین لازم را برای مقداردهی اولیه استخر ارائه می‌دهد. بر اساس گفتگو با توسعه دهنده GnuPG ورنر کوخ، مولر معتقد است که گارانتی تنها دلیلی است که GnuPG در حال حاضر مستقیماً از /dev/random می خواند. اما اگر یک رابط غیرمجاز وجود داشته باشد که مستعد انکار سرویس باشد (همانطور که /dev/random امروزی است)، لوتومیرسکی استدلال می‌کند که توسط برخی برنامه‌ها مورد سوء استفاده قرار خواهد گرفت.
Theodore Yue Tak Ts'o، توسعه دهنده زیرسیستم اعداد تصادفی لینوکس، به نظر می رسد نظر خود را در مورد نیاز به یک استخر مسدود کننده تغییر داده است. او گفت که حذف این استخر به طور موثری از این ایده که لینوکس یک تولید کننده اعداد تصادفی واقعی (TRNG) دارد خلاص می شود: "این مزخرف نیست، زیرا این دقیقاً همان کاری است که *BSD همیشه انجام داده است."
او همچنین نگران است که ارائه مکانیزم TRNG به سادگی به عنوان طعمه ای برای توسعه دهندگان برنامه عمل کند و معتقد است که در واقع با توجه به انواع مختلف سخت افزارهای پشتیبانی شده توسط لینوکس، تضمین TRNG در هسته غیرممکن است. حتی توانایی کار با تجهیزات فقط با امتیازات ریشه مشکل را حل نمی کند: "توسعه دهندگان برنامه مشخص می کنند که برنامه آنها به عنوان ریشه برای اهداف امنیتی نصب شود، به طوری که این تنها راهی است که می توانید به اعداد تصادفی "واقعا خوب" دسترسی پیدا کنید."
مولر از او پرسید که آیا کائو اجرای استخر مسدودکننده ای را که خودش مدت ها پیشنهاد کرده بود، کنار گذاشته است؟ کائو پاسخ داد که قصد دارد وصله های Lutomirsky را بگیرد و فعالانه با افزودن یک رابط مسدود کننده به هسته مخالف است.
"هسته نمی تواند هیچ تضمینی در مورد اینکه آیا منبع نویز به درستی مشخص شده است یا خیر. تنها چیزی که یک توسعه دهنده GPG یا OpenSSL می تواند دریافت کند این است که احساس مبهمی دارد که TRUERANDOM "بهتر" است و از آنجایی که آنها امنیت بیشتری می خواهند، بدون شک سعی خواهند کرد از آن استفاده کنند. در نقطه‌ای مسدود می‌شود، و زمانی که یک کاربر هوشمند دیگر (شاید یک متخصص توزیع) آن را در اسکریپت init قرار می‌دهد و سیستم‌ها از کار می‌افتند، کاربران فقط باید به خود لینوس توروالدز شکایت کنند.
کائو همچنین از دادن روشی به رمزنگاران و کسانی که واقعاً به TRNG نیاز دارند، برای برداشت آنتروپی خود در فضای کاربر برای استفاده هر طور که مناسب می‌دانند، حمایت می‌کند. او می‌گوید که جمع‌آوری آنتروپی فرآیندی نیست که بتواند توسط کرنل روی تمام سخت‌افزارهای مختلفی که پشتیبانی می‌کند انجام شود، و همچنین هسته نمی‌تواند میزان آنتروپی ارائه شده توسط منابع مختلف را تخمین بزند.
هسته نباید منابع مختلف نویز را با هم مخلوط کند و مطمئناً نباید ادعا کند که وقتی می‌خواهد نوعی «بازی آنتروپی پیچ‌خورده» را روی یک CPU بسیار ساده انجام دهد، بداند چند بیت آنتروپی دریافت می‌کند. معماری برای کاربران مصرف کننده IOT/موردهای جاسازی شده که در آن همه چیز با یک نوسانگر اصلی هماهنگ نیست، جایی که هیچ دستورالعملی برای سفارش مجدد یا تغییر نام رجیستر و غیره وجود ندارد.
می‌توانید درباره ارائه ابزارهایی صحبت کنید که سعی در انجام این محاسبات دارند، اما چنین کارهایی باید روی سخت‌افزار هر کاربر انجام شود، که برای اکثر کاربران توزیع عملی نیست. اگر این فقط برای رمزنگاران در نظر گرفته شده است، اجازه دهید در فضای کاربری آنها انجام شود. و بیایید GPG، OpenSSL و غیره را ساده نکنیم تا همه بگویند "تصادفی واقعی" می خواهیم و به کمتر راضی نمی شویم. می‌توانیم در مورد نحوه ارائه رابط‌ها به رمزنگارها صحبت کنیم تا بتوانند با دسترسی به منابع اصلی نویز، جداسازی‌شده و نام‌گذاری شده، اطلاعات مورد نیاز خود را به دست آورند و شاید به نحوی منبع نویز بتواند خود را در یک کتابخانه یا برنامه فضای کاربر تأیید کند."
بحث هایی در مورد این که چنین رابطی ممکن است چگونه باشد، وجود داشت، زیرا برای مثال ممکن است پیامدهای امنیتی برای برخی رویدادها وجود داشته باشد. کائو خاطرنشان کرد که کدهای اسکن صفحه کلید (یعنی ضربات کلید) به عنوان بخشی از مجموعه آنتروپی در یک استخر مخلوط می شوند: "این را به فضای کاربر وارد کنید، حتی از طریق یک تماس سیستمی ممتاز، حداقل عاقلانه نیست." این کاملاً ممکن است که زمان‌بندی رویدادهای دیگر ممکن است نوعی نشت اطلاعات را از طریق کانال‌های جانبی ایجاد کند.
بنابراین به نظر می رسد یک مشکل طولانی مدت با زیرسیستم اعداد تصادفی لینوکس در راه حل است. تغییراتی که اخیراً زیرسیستم اعداد تصادفی متحمل شده است، در واقع تنها منجر به مشکلات DoS در هنگام استفاده از آن شده است. اکنون راه‌های کارآمدی برای بدست آوردن بهترین اعداد تصادفی وجود دارد که هسته می‌تواند ارائه دهد. اگر TRNG همچنان در لینوکس مطلوب است، پس این نقص باید در آینده برطرف شود، اما به احتمال زیاد این کار در خود هسته انجام نخواهد شد.
چند تبلیغ 🙂
از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید , یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).
Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا در هلند! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید
منبع: www.habr.com