NIST SP 800-90A: معايير DRBG

تحتاج العمليات التشفيرية إلى أرقام عشوائية عالية الجودة: لإنشاء المفاتيح، وnonces، ومتجهات التهيئة IVs، وsalts، ورموز الجلسات. تجمع مولدات الأرقام العشوائية الحقيقية (TRNGs) الإنتروبيا من مصادر مادية، مثل ضوضاء العتاد والمقاطعات والضوضاء الحرارية، لكنها بطيئة وغير متاحة دائمًا، ولا سيما في الآلات الافتراضية أو أثناء الإقلاع المبكر. وتحل مولدات البتات العشوائية الحتمية (DRBGs) هذه المشكلة: إذ يُزرع DRBG بكمية صغيرة من الإنتروبيا الحقيقية، ثم تُستخدم خوارزمية تشفيرية لتمديدها إلى تدفق كبير من البتات شبه العشوائية التي لا يستطيع خصم ذو قدرة حسابية تمييزها عن العشوائية الحقيقية. ويحدد NIST SP 800-90A ثلاث آليات DRBG معتمدة تُستخدم في جميع تطبيقات التشفير الحديثة تقريبًا.

يعمل DRBG عبر ثلاث عمليات أساسية. Instantiate: تهيئة الحالة الداخلية لـ DRBG باستخدام entropy_input، القادم من مصدر إنتروبيا، وnonce، وهي قيمة تُستخدم مرة واحدة لضمان التفرد، واختياريًا personalization_string، وهو سياق خاص بالتطبيق. Generate: إنتاج العدد المطلوب من البتات شبه العشوائية وتحديث الحالة الداخلية لمنع التراجع. Reseed: حقن إنتروبيا جديدة في حالة DRBG لتوفير مقاومة التنبؤ — فبعد إعادة البذر، حتى الخصم الذي كان يعرف الحالة السابقة لا يستطيع التنبؤ بالمخرجات المستقبلية. ويحدد NIST فواصل التوليد القصوى (reseed_interval):‏ 2^48 طلبًا قبل وجوب إعادة البذر في أنواع DRBG الثلاثة.

يحدد NIST SP 800-90A أربعة مستويات لقوة الأمان: 112 و128 و192 و256 بتًا. وتحدد قوة الأمان الحد الأدنى من الإنتروبيا المطلوبة عند إنشاء المثيل وجودة المخرجات المُولّدة. ولتحقيق أمان قدره 128 بتًا، يجب أن يوفر إدخال الإنتروبيا 128 بتًا من الإنتروبيا على الأقل. والعلاقة هي: security_strength بتًا من الإنتروبيا ← مخرجات DRBG لا يستطيع خصم ينفذ 2^security_strength عملية تمييزها حسابيًا عن العشوائية. وتُقيّد اختيارات طول المفتاح، مثل AES-128 مقابل AES-256، واختيارات دالة التجزئة، مثل SHA-256 مقابل SHA-512، بحيث تطابق قوة الأمان المطلوبة أو تتجاوزها. وتُعد المبالغة في تحديد المعلمات، مثل استخدام SHA-512 لأمان قدره 128 بتًا، آمنة لكنها مهدرة للموارد؛ أما تحديد المعلمات بأقل من المطلوب فيقوض الأمان.

يحافظ Hash_DRBG على قيمتي حالة: V، وهي قيمة تُستخدم لتوليد المخرجات، وC، وهو ثابت يُضاف أثناء التوليد. وفي Generate، ينتج hash_gen البتات بتكرار H(0x01 || V)، ثم H(0x01 || V+1)، وهكذا حتى تتوفر مخرجات كافية؛ وبعد ذلك تُحدّث V وفق V = V + H(0x03 || V) + C + reseed_counter. وتستخدم Reseed دالة Hash_df، وهي دالة اشتقاق تعتمد على التجزئة، لدمج V الحالية مع إنتروبيا جديدة من أجل إنتاج V وC جديدتين. يتميز Hash_DRBG بسهولة التنفيذ وبساطة تحليل الأمان، مما يجعله مناسبًا للبيئات محدودة الموارد. ويوصي NIST بإنشاء المثيل باستخدام SHA-256 أو SHA-512. ويُستخدم Hash_DRBG في SHA1PRNG الخاص بـ Java، وهو إصدار قديم، وفي DRBG القديم الخاص بـ OpenSSL.

يحافظ HMAC_DRBG على الحالة (المفتاح K والقيمة V). وفي Generate، يكرر V = HMAC(K, V) حتى إنتاج مخرجات كافية؛ ثم يحدّث K وفق K = HMAC(K, V || 0x00) وV وفق V = HMAC(K, V). أما Update فيأخذ additional_input ويعيد بذر K وV باستخدام عمليات HMAC. ويتميز HMAC_DRBG ببرهان أمان واضح يستند إلى أمان HMAC، أي افتراض PRF على HMAC. وهو DRBG الأكثر توصيةً على نطاق واسع: إذ يستخدمه OpenSSL منذ 1.1.1 وmbedTLS وwolfSSL ومعظم حزم TLS. ويوفر تركيب HMAC مزجًا مدمجًا بين الاستدعاءات المتتالية، مما يجعل تنفيذ هجمات التراجع أصعب حتى إذا كُشفت الحالة جزئيًا.

يستخدم CTR_DRBG شيفرة كتل، هي AES، في نمط العداد. وتتكون الحالة من المفتاح K والعداد V. وفي Generate، يشفّر قيم العداد المتتالية E(K, V)، ثم E(K, V+1)، وهكذا، ويزيد V. أما Update فيستخدم Block_Cipher_df لاشتقاق K وV جديدين من additional_input. ويُعد CTR_DRBG أسرع مولد DRBG — إذ تجعل مسرّعات AES-NI العتادية سرعته أكبر بفوارق هائلة من مولدات DRBG المعتمدة على التجزئة في المعالجات الحديثة. وهو مولد DRBG الافتراضي في Windows CNG، حيث يستخدم CryptGenRandom ‏CTR_DRBG مع AES-256، وفي OpenSSL 3.0، وهو الإعداد الافتراضي، وفي مولد الأرقام العشوائية لنواة Linux، عبر استدعاء النظام getrandom. ويعتمد أمان CTR_DRBG على كون AES تبديلًا شبه عشوائي، وهو أمر مدعوم جيدًا بتحليل امتد لعقود.

مقاومة التنبؤ خاصية تكون فيها مخرجات DRBG غير قابلة للتنبؤ حتى بالنسبة إلى خصم سبق أن اخترق حالة DRBG، شريطة مزج إنتروبيا جديدة عبر إعادة البذر. ويستدعي DRBG الذي تكون فيه prediction_resistance_flag=true مصدر الإنتروبيا قبل كل استدعاء لـ Generate لحقن إنتروبيا جديدة. ومن دون مقاومة التنبؤ، يتيح اختراق الحالة في الزمن T حساب جميع المخرجات المستقبلية، وبذلك تنكسر السرية المستقبلية. أما الأمان العكسي، الذي يُسمى أيضًا مقاومة التراجع، فيعني أن المخرجات السابقة تظل غير قابلة للتنبؤ حتى عند معرفة الحالة الحالية — ويحقق HMAC_DRBG وCTR_DRBG ذلك عبر خطوات Update التي تشتق مفتاحًا جديدًا من الحالة الحالية بعد كل Generate.

يحدد SP 800-90A خوارزميات DRBG، لكنه لا يحدد مصدر الإنتروبيا. ويحدد SP 800-90B متطلبات مصادر الإنتروبيا: إذ يجب توصيف مصادر الضوضاء العتادية والتحقق من صحتها، ويجب أن تكون تقديرات الإنتروبيا محافظة، كما يجب أن تكشف اختبارات السلامة عن أعطال مصدر الإنتروبيا. ويحدد SP 800-90C كيفية دمج مصادر الإنتروبيا مع DRBGs لتكوين مولدات كاملة للبتات العشوائية. ومن مصادر الإنتروبيا الشائعة: RDRAND/RDSEED في وحدة المعالجة المركزية، وهو مولد عتادي للأرقام العشوائية متاح في وحدات Intel وAMD منذ عام 2012؛ وإنتروبيا نظام التشغيل، مثل /dev/urandom في Linux وBCryptGenRandom في Windows؛ ووحدات أمان العتاد؛ ومولد الأرقام العشوائية في TPM 2.0؛ والضوضاء البيئية، مثل توقيت القرص وتقلبات الشبكة. وتتطلب حالات انخفاض الإنتروبيا، مثل الآلات الافتراضية والإقلاع المبكر، معالجة خاصة لتجنب البذور الضعيفة.

يفرض FIPS 140-3، وهو المعيار الحالي للتحقق من وحدات التشفير، استخدام DRBGs المحددة في NIST SP 800-90A لتوليد جميع الأرقام العشوائية داخل الوحدات المعتمدة. ويجب على الوحدة: استخدام DRBG معتمد، أي Hash أو HMAC أو CTR؛ والزرع من مصدر إنتروبيا معتمد يستوفي متطلبات SP 800-90B؛ وإجراء اختبارات ذاتية عند التشغيل (POST) للتحقق من عمل DRBG؛ وتنفيذ اختبارات مستمرة لمولد الأرقام العشوائية (CRNGT) لاكتشاف أعطال الإنتروبيا العالقة عند الصفر أو العالقة عند الواحد؛ ودعم Reseed عندما يشير مصدر الإنتروبيا إلى توفر إنتروبيا. وتتطلب وحدات HSM، مثل Thales Luna وAWS CloudHSM وUtimaco، وبطاقات تسريع TLS، وأجهزة تشفير الشبكات عادةً وحدات معتمدة وفق FIPS 140-3، مما يدفع إلى اعتماد SP 800-90A.

تحافظ أنظمة التشغيل الحديثة على DRBG على مستوى النواة، وتزوّده بالبذرة من مصادر إنتروبيا عتادية. يستخدم Linux ‏DRBG مبنيًا على ChaCha20 (منذ النواة 5.17، بعد استبدال التصميم الأقدم الشبيه بـ Fortuna)، وتأتي بذرته من RDRAND والمقاطعات وأحداث القرص والشبكة. يعيد ‎/dev/urandom‎ مخرجات DRBG ولا يحجب التنفيذ بعد تزويده بالبذرة أوليًا. أما ‎/dev/random‎ فيحجب التنفيذ إلى أن تتوفر إنتروبيا كافية (وهو سلوك قديم أزيل في معظمه من النوى الحديثة). وتُعدّ استدعاءات النظام getrandom(2) الواجهة الحديثة، ولا تحجب التنفيذ إلا أثناء الإقلاع المبكر، قبل تزويد DRBG بالبذرة. يستخدم Windows ‏CTR_DRBG (AES-256) في مولّد الأرقام العشوائية داخل النواة، وتأتي بذرته من TPM والأحداث العتادية. ينبغي للتطبيقات استخدام DRBG الخاص بنظام التشغيل عبر واجهات برمجة التطبيقات عالية المستوى، بدلًا من تزويد DRBGs الخاصة بها بالبذور اعتمادًا على الطوابع الزمنية أو معرّفات العمليات PID.

تنشأ ثغرات DRBG في العالم الحقيقي من أخطاء التنفيذ، لا من نقاط ضعف الخوارزمية. (1) التزويد غير الكافي بالبذرة: يؤدي استخدام الطابع الزمني الحالي أو PID وحده إلى بذرة يمكن للمهاجم تخمينها. (2) عدم الانتباه إلى fork: عند إنشاء عملية فرعية، تشترك العملية الأصلية والفرعية في حالة DRBG نفسها، فتولّدان أرقامًا عشوائية متطابقة. الإصلاح: إعادة تزويد DRBG بالبذرة بعد fork (باستخدام pthread_atfork أو استدعاء getrandom صريح). (3) إعادة استخدام لقطات VM: عند استعادة لقطة VM، تعود حالة DRBG إلى حالة اللقطة، فتولّد مخرجات ظهرت سابقًا. الإصلاح: حقن إنتروبيا فريدة عند بدء تشغيل VM (باستخدام VIRTIO RNG). (4) تجاهل إخفاق اختبارات السلامة بصمت: إن واصل DRBG التوليد بعد اكتشاف إخفاق في الإنتروبيا، فسيوفر مخرجات يمكن للمهاجم التنبؤ بها. (5) إعادة استخدام nonces بين مثيلات DRBG.

ما الخاصية التي توفرها إعادة تزويد DRBG بالبذرة باستخدام إنتروبيا جديدة؟

يعرّف NIST SP 800-90A ثلاث آليات DRBG معتمدة: ‏Hash_DRBG (تجزئة تكرارية وبسيطة)، وHMAC_DRBG (مبني على HMAC، مع برهان أمني واضح، ومستخدم على نطاق واسع)، وCTR_DRBG (نمط عدّاد AES، وهو الأسرع عبر AES-NI والافتراضي في Windows/OpenSSL). وتشترك جميعها في دورة الحياة Instantiate/Generate/Reseed، مع حد reseed_interval البالغ ‎2^48‎. وتحدد قوة الأمان (من 112 إلى 256 بتًا) متطلبات الإنتروبيا. وتتطلب مقاومة التنبؤ إعادة تزويد DRBG بالبذرة قبل كل استدعاء Generate. ويفرض FIPS 140-3 استخدام DRBGs وفق SP 800-90A مع مصادر إنتروبيا وفق SP 800-90B. ويُعد عدم الانتباه إلى fork، وإعادة استخدام لقطات VM، والتزويد غير الكافي بالبذرة، أهم مشكلات التنفيذ في العالم الحقيقي.