استنزاف الإنتروبيا وأخطاء المفاتيح الضعيفة

يحدث نقص الإنتروبيا عندما يفتقر النظام إلى مدخلات غير قابلة للتنبؤ تكفي لتهيئة مولد CSPRNG ببذرته. ويحدث ذلك في الأجهزة المضمنة حديثة الإقلاع، أو الخوادم الافتراضية، أو الأنظمة التي لا تتلقى إدخالًا من المستخدم. عندها تصبح مخرجات RNG قابلة للتنبؤ.

في عام 2006، أزال أحد مطوري Debian سطرًا أبلغ عنه Valgrind: MD_Update(&m, buf, j). كان هذا السطر مصدر الإنتروبيا. وكانت النتيجة أن OpenSSL على Debian لم يُهيّأ إلا باستخدام PID، أي بحد أقصى 32,768 قيمة. وأصبحت جميع المفاتيح المولدة بين عامي 2006 و2008 ضمن مجموعة من 32,768 احتمالًا.

تعرضت مفاتيح RSA وDSA وECDSA، ومفاتيح مضيفي SSH، وشهادات TLS، ومفاتيح SSL VPN المولدة على أنظمة Debian/Ubuntu بين عامي 2006 و2008 للاختراق. والأنظمة المتأثرة هي Debian Etch وDebian Lenny وUbuntu 7.04-8.04. نُشرت القوائم السوداء وأُلغيت الشهادات.

يمكن استنساخ الآلات الافتراضية مع حالة قرص متطابقة. وإذا ولّدت الآلتان مفاتيح انطلاقًا من حالة CSPRNG نفسها، فستنتجان المفاتيح نفسها. يحقن مشرفو الآلات الافتراضية الآن الإنتروبيا عبر VirtIO RNG أو جداول ACPI، لكن الآلات الافتراضية سيئة الإعداد تظل معرضة لهذا الخطر عند الإقلاع.

غالبًا ما تولد أجهزة إنترنت الأشياء، مثل أجهزة التوجيه والكاميرات، مفاتيح SSH/TLS عند الإقلاع الأول قبل تراكم قدر كافٍ من الإنتروبيا. وقد وجدت الدراسات ملايين الأجهزة التي تشترك في بضعة آلاف من أزواج مفاتيح RSA، لأنها جميعًا أُهيئت من حالة إقلاع منخفضة الإنتروبيا نفسها.

جمع Lenstra وآخرون (2012) عددًا قدره 11.7 مليون شهادة TLS وحسبوا القواسم المشتركة الأكبر لكل زوج. ووجدوا 12,720 مفتاح RSA يشترك في عامل أولي، ما يعني إمكانية تحليل المفتاحين بالكامل. وقد كُسر 0.2% من جميع المفاتيح العامة. والسبب هو عدم كفاية إنتروبيا الإقلاع.

يتطلب ECDSA قيمة nonce عشوائية وفريدة k لكل توقيع. وإذا أُعيد استخدام k (أو كانت ضعيفة)، يمكن استرداد المفتاح الخاص فورًا: d = (s1-s2)^{-1} * (z1-z2) * k / (r1-r2) mod n. استخدمت PS3 من Sony قيمة k=constant، ولذلك أمكن توقيع جميع الألعاب باستخدام المفتاح المسترد.

كانت Java SecureRandom على Android 4.x تُهيّأ باستخدام وقت النظام في ظروف معينة. وقد ولّدت عدة تطبيقات لمحافظ Bitcoin توقيعات باستخدام قيمة nonce k نفسها، مما أدى إلى تسريب المفاتيح الخاصة. وسُرقت ملايين الدولارات. وأصلحت Google تنفيذ SecureRandom.

الأدوات: ssh-vulnkey (يفحص مقابل القائمة السوداء لمفاتيح Debian الضعيفة)، وbadkeys (يفحص شهادات TLS بحثًا عن العوامل الأولية المعروفة بضعفها)، وخوارزمية GCD-batch لتدقيق مفاتيح RSA على نطاق واسع. وتتيح سجلات Certificate Transparency إجراء تحليل على مستوى مجموعة المستخدمين بأكملها.

استخدموا getrandom(GRND_RANDOM) عند توليد أول مفتاح. واقرؤوا من /dev/urandom بعد انتظار التهيئة الأولية للبذرة (تحققوا من أن /proc/sys/kernel/random/entropy_avail > 128). واستخدموا مولدًا عتاديًا للأرقام العشوائية (RDRAND) بوصفه إنتروبيا إضافية. لا تولدوا مفاتيح عند الإقلاع الأول دون تأخير مطلقًا.

احتفظوا بحالة CSPRNG عبر عمليات إعادة الإقلاع: احفظوا 32 بايت من /dev/urandom في ملف بذرة عند إيقاف التشغيل، ثم اقرأوها وأعيدوا إدخالها عند الإقلاع. يوفر ذلك استمرارية للإنتروبيا عبر عمليات الإقلاع البارد. ينفذ Linux ذلك تلقائيًا، لكن الأنظمة المضمنة غالبًا لا تفعل ذلك.

يؤدي نقص الإنتروبيا إلى مفاتيح قابلة للتنبؤ. ومن حالات الاختراق الفعلية: OpenSSL على Debian (بذرة تعتمد على PID فقط)، وهجمات GCD على أجهزة إنترنت الأشياء، وإعادة استخدام nonce في ECDSA على PS3، ومحفظة Bitcoin على Android. احرصوا دائمًا على التهيئة من إنتروبيا نظام التشغيل، ودققوا بعناية في توليد المفاتيح على الأنظمة المضمنة. التالي: توليد المفاتيح وقيم nonce وIV بأمان.