من المعروف أن /dev/random، وهو مولد أرقام عشوائية زائفة وآمن تشفيريًا (CSPRNG)، يعاني من مشكلة واحدة مزعجة: الحظر. تشرح هذه المقالة كيف يمكنك حلها.
على مدى الأشهر القليلة الماضية، تم إعادة صياغة مرافق توليد الأرقام العشوائية في النواة بشكل طفيف، ولكن تم حل المشاكل في هذا النظام الفرعي على مدار العام الأوسع . معظم تم إجراؤها لمنع استدعاء نظام getrandom() من الحظر لفترة طويلة عند تشغيل النظام، ولكن السبب الأساسي لذلك هو سلوك الحظر للتجميع العشوائي. كان من الممكن أن يؤدي التصحيح الأخير إلى إزالة هذا التجمع وكان من المتوقع أن يتجه نحو النواة الرئيسية.
نشر آندي لوتوميرسكي الإصدار الثالث من التصحيح في نهاية شهر ديسمبر. يساهم "تغييران دلاليان رئيسيان على واجهات برمجة تطبيقات Linux العشوائية". يضيف التصحيح علامة GRND_INSECURE جديدة إلى استدعاء النظام getrandom() (على الرغم من أن Lutomirsky يشير إليها باسم getentropy()، والتي يتم تنفيذها في glibc باستخدام getrandom() مع العلامات الثابتة)؛ تؤدي هذه العلامة إلى قيام المكالمة بإرجاع كمية البيانات المطلوبة دائمًا، ولكن دون ضمان أن البيانات عشوائية. ستبذل النواة ببساطة قصارى جهدها لإنتاج أفضل البيانات العشوائية المتوفرة لديها في الوقت المحدد. "ربما يكون أفضل ما يمكنك فعله هو تسميته "غير آمن" (غير آمن) لمنع استخدام واجهة برمجة التطبيقات هذه للأشياء التي تحتاج إلى الأمان."
تقوم التصحيحات أيضًا بإزالة تجمع الحظر. تحتفظ النواة حاليًا بمجموعتي بيانات عشوائيتين، واحدة تتوافق مع /dev/random والأخرى لـ /dev/urandom، كما هو موضح في هذا 2015. تجمع الحظر هو تجمع /dev/random؛ سيتم حظر عمليات القراءة لهذا الجهاز (بمعنى اسمه) حتى يتم جمع إنتروبيا "كافية" من النظام لتلبية الطلب. يتم أيضًا حظر القراءات الإضافية من هذا الملف إذا لم يكن هناك إنتروبيا كافية في المجمع.
تعني إزالة تجمع القفل أن القراءة من /dev/random تتصرف مثل getrandom() مع تعيين العلامات على الصفر (ويحول علامة GRND_RANDOM إلى noop). بمجرد تهيئة منشئ الأرقام العشوائية المشفرة (CRNG)، لن يتم حظر القراءة من /dev/random واستدعاءات getrandom(...,0) وستعيد الكمية المطلوبة من البيانات العشوائية.
يقول لوتوميرسكي: "أعتقد أن مجموعة حظر Linux أصبحت قديمة. يقوم CRNG Linux بإنشاء مخرجات جيدة بما يكفي لاستخدامها في إنشاء المفاتيح. مجموعة الحظر ليست أقوى بأي معنى مادي وتتطلب الكثير من البنية التحتية ذات القيمة المشكوك فيها لدعمها.
تم إجراء التغييرات بهدف ضمان عدم تأثر البرامج الحالية فعليًا، وفي الواقع، ستكون هناك مشكلات أقل مع فترات الانتظار الطويلة لأشياء مثل إنشاء مفتاح GnuPG.
"يجب ألا تؤدي هذه الأحداث إلى تعطيل أي برامج موجودة. /dev/urandom يبقى دون تغيير. لا يزال /dev/random يحظر فورًا عند التمهيد، ولكنه يحظر بشكل أقل من ذي قبل. getentropy() مع الأعلام الموجودة سيُرجع نتيجة مناسبة تمامًا للأغراض العملية كما كان من قبل."
وأشار لوتوميرسكي إلى أنه لا يزال هناك سؤال مفتوح حول ما إذا كان يجب على النواة توفير ما يسمى بـ "الأرقام العشوائية الحقيقية"، وهو ما كان من المفترض أن تفعله النواة المحظورة إلى حد ما. وهو يرى سببا واحدا فقط لذلك: "الامتثال للمعايير الحكومية". اقترح Lutomirsky أنه إذا كانت النواة ستوفر ذلك، فيجب أن يتم ذلك من خلال واجهة مختلفة تمامًا، أو يجب نقلها إلى مساحة المستخدم، مما يسمح للمستخدم باسترداد عينات الأحداث الأولية التي يمكن استخدامها لإنشاء تجمع القفل هذا.
اقترح ستيفان مولر مجموعته يمكن أن يكون برنامج Linux Random Number Generator (LRNG) (الإصدار 26 الذي تم إصداره حاليًا) وسيلة لتوفير أرقام عشوائية حقيقية للتطبيقات التي تحتاج إليها. LRNG "متوافق تمامًا مع إرشادات SP800-90B بشأن مصادر الإنتروبيا المستخدمة لإنشاء البتات العشوائية"، مما يجعله حلاً لمشكلة المعايير الحكومية.
اعترض ماثيو جاريت على مصطلح «البيانات العشوائية الحقيقية»، مشيرًا إلى أن الأجهزة التي تم أخذ عينات منها يمكن من حيث المبدأ تصميمها بدقة كافية لجعلها قابلة للتنبؤ بها: «نحن لا نأخذ عينات من الأحداث الكمومية هنا».
أجاب مولر أن المصطلح يأتي من المعيار الألماني AIS 31 لوصف مولد الأرقام العشوائي الذي ينتج نتيجة فقط "بنفس المعدل الذي ينتج فيه مصدر الضوضاء الأساسي الإنتروبيا".
وبغض النظر عن الاختلافات في المصطلحات، فإن وجود مجموعة قفل كما هو مقترح من خلال تصحيحات LRNG سيؤدي ببساطة إلى مشكلات مختلفة، على الأقل إذا تم الوصول إليها دون امتيازات.
كما قال لوتوميرسكي: "هذا لا يحل المشكلة. إذا قام مستخدمان مختلفان بتشغيل برامج غبية مثل gnupg، فسوف يستنزفان بعضهما البعض. أرى أن هناك حاليًا مشكلتين رئيسيتين مع /dev/random: فهو عرضة لـ DoS (أي استنزاف الموارد أو التأثير الضار أو شيء مشابه)، وبما أنه لا يتطلب أي امتيازات لاستخدامه، فهو أيضًا عرضة لإساءة الاستخدام. Gnupg خطأ، إنه انهيار كامل. إذا أضفنا واجهة جديدة غير مميزة سيستخدمها برنامج gnupg والبرامج المشابهة، فسوف نخسر مرة أخرى."
أشار مولر إلى أن إضافة getrandom() ستسمح الآن لـ GnuPG باستخدام هذه الواجهة، لأنها ستوفر الضمان اللازم لتهيئة المجمع. استنادًا إلى المناقشات مع مطور GnuPG Werner Koch، يعتقد مولر أن الضمان هو السبب الوحيد الذي يجعل GnuPG يقرأ حاليًا مباشرة من /dev/random. ولكن إذا كانت هناك واجهة غير مميزة وعرضة لرفض الخدمة (كما هو الحال اليوم /dev/random)، فإن Lutomirsky يجادل بأنه سيتم إساءة استخدامها من قبل بعض التطبيقات.
يبدو أن ثيودور يو تاك تسو، مطور النظام الفرعي للأرقام العشوائية في Linux، قد غير رأيه بشأن الحاجة إلى مجموعة حظر. وقال إن إزالة هذا التجمع من شأنه أن يتخلص بشكل فعال من فكرة أن Linux لديه منشئ أرقام عشوائية حقيقية (TRNG): "هذا ليس هراء، لأن هذا هو بالضبط ما فعلته *BSD دائمًا."
كما أنه يشعر بالقلق من أن توفير آلية TRNG سيكون ببساطة بمثابة طعم لمطوري التطبيقات ويعتقد أنه في الواقع، نظرًا للأنواع المختلفة من الأجهزة التي يدعمها Linux، من المستحيل ضمان TRNG في النواة. حتى القدرة على العمل مع المعدات التي تتمتع بامتيازات الجذر فقط لن تحل المشكلة: "يحدد مطورو التطبيقات تثبيت تطبيقاتهم كجذر لأغراض أمنية، بحيث تكون هذه هي الطريقة الوحيدة التي يمكنك من خلالها الوصول إلى الأرقام العشوائية "الجيدة حقًا"."
وتساءل مولر عما إذا كان تساو قد تخلى عن تنفيذ مجموعة الحظر التي اقترحها هو نفسه منذ فترة طويلة. رد Cao بأنه يخطط لأخذ تصحيحات Lutomirsky ويعارض بشدة إضافة واجهة حظر مرة أخرى إلى النواة.
"لا تستطيع النواة تقديم أي ضمانات فيما يتعلق بما إذا كان مصدر الضوضاء قد تم تمييزه بشكل صحيح أم لا. الشيء الوحيد الذي يمكن أن يحصل عليه مطور GPG أو OpenSSL هو شعور غامض بأن TRUERANDOM "أفضل"، وبما أنهم يريدون المزيد من الأمان، فسيحاولون استخدامه بلا شك. في مرحلة ما سيتم حظره، وعندما يقوم مستخدم ذكي آخر (ربما متخصص توزيع) بإدراجه في البرنامج النصي init وتتوقف الأنظمة عن العمل، لن يكون على المستخدمين سوى تقديم شكوى إلى Linus Torvalds نفسه.
يدعو Cao أيضًا إلى منح مصممي التشفير وأولئك الذين يحتاجون بالفعل إلى TRNG طريقة لحصد الإنتروبيا الخاصة بهم في مساحة المستخدم لاستخدامها على النحو الذي يرونه مناسبًا. ويقول إن جمع الإنتروبيا ليس عملية يمكن إجراؤها بواسطة النواة على جميع الأجهزة المختلفة التي تدعمها، ولا تستطيع النواة نفسها تقدير مقدار الإنتروبيا التي توفرها المصادر المختلفة.
"لا ينبغي للنواة أن تخلط مصادر الضوضاء المختلفة معًا، وبالتأكيد لا ينبغي أن تحاول الادعاء بمعرفة عدد أجزاء الإنتروبيا التي تحصل عليها عندما تحاول لعب نوع من "لعبة الإنتروبيا المضطربة" على وحدة معالجة مركزية بسيطة للغاية "الهندسة المعمارية للمستخدمين المستهلكين. IOT / الحالات المضمنة حيث يكون كل شيء غير متزامن مع مذبذب رئيسي واحد، حيث لا توجد تعليمات وحدة المعالجة المركزية لإعادة ترتيب أو إعادة تسمية السجل، وما إلى ذلك. "
"يمكنك التحدث عن توفير الأدوات التي تحاول إجراء هذه الحسابات، ولكن مثل هذه الأشياء يجب القيام بها على أجهزة كل مستخدم، وهو أمر غير عملي بالنسبة لمعظم مستخدمي التوزيع. إذا كان هذا مخصصًا لمتخصصي التشفير فقط، فليكن ذلك في مساحة المستخدم الخاصة بهم. ودعونا لا نقوم بتبسيط GPG وOpenSSL وما إلى ذلك بحيث يقول الجميع "نريد "العشوائية الحقيقية" ولن نقبل بأقل من ذلك." يمكننا التحدث عن كيفية توفير واجهات لمتخصصي التشفير حتى يتمكنوا من الحصول على المعلومات التي يحتاجون إليها عن طريق الوصول إلى مصادر الضوضاء الأولية، المنفصلة والمسماة، وربما بطريقة ما يمكن لمصدر الضوضاء أن يصادق على نفسه إلى مكتبة أو تطبيق مساحة المستخدم."
وكانت هناك بعض المناقشات حول الشكل الذي قد تبدو عليه هذه الواجهة، لأنه على سبيل المثال قد تكون هناك آثار أمنية لبعض الأحداث. وأشار كاو إلى أن رموز فحص لوحة المفاتيح (أي ضغطات المفاتيح) يتم خلطها في مجموعة كجزء من مجموعة الإنتروبيا: "إن جلب هذا إلى مساحة المستخدم، حتى من خلال استدعاء نظام مميز، سيكون من غير الحكمة على أقل تقدير." من المحتمل جدًا أن تؤدي توقيتات الأحداث الأخرى إلى حدوث نوع من تسرب المعلومات عبر القنوات الجانبية.
لذا يبدو أن المشكلة الطويلة الأمد المتعلقة بالنظام الفرعي للأرقام العشوائية في Linux في طريقها إلى الحل. إن التغييرات التي خضع لها النظام الفرعي للأرقام العشوائية مؤخرًا لم تؤدي إلا إلى حدوث مشكلات DoS أثناء استخدامه. توجد الآن طرق فعالة للحصول على أفضل الأرقام العشوائية التي يمكن أن توفرها النواة. إذا كان TRNG لا يزال مرغوبًا فيه على Linux، فسيتعين معالجة هذا الخلل في المستقبل، ولكن على الأرجح لن يتم ذلك داخل النواة نفسها.
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com