الأسس الداخلية لـ Hash-DRBG وHMAC-DRBG وCTR-DRBG

تحافظ كل آلية من آليات NIST الثلاث لـ DRBG على مكوّنات مختلفة للحالة الداخلية، بما يعكس نهجها الخوارزمي الأساسي. يخزّن Hash_DRBG المتغير V (بذرة بطول الهاش) والمتغير C (ثابتًا مشتقًا من V ويُستخدم أثناء توليد المخرجات). ويخزّن HMAC_DRBG المفتاح السري K (مفتاحًا بطول الهاش) والقيمة V (قيمة تسلسل بطول الهاش). أما CTR_DRBG فيخزّن المفتاح K (مفتاح AES) وV (عدادًا بطول الكتلة). وتحافظ الآليات الثلاث على reseed_counter لتتبّع استدعاءات التوليد منذ آخر تزويد بالبذرة. ويحدد حجم الحالة مقدار الذاكرة المستخدم؛ إذ يستخدم Hash/HMAC_DRBG مع SHA-256 حالة حجمها 64 بايتًا، بينما يستخدم CTR_DRBG مع AES-256 حالة حجمها 48 بايتًا (مفتاح من 32 بايتًا + عدّاد من 16 بايتًا).

يستخدم Hash_DRBG ‏Hash_df (دالة اشتقاق الهاش) لاشتقاق الحالة من مادة الإنتروبيا. تنفّذ Hash_df(input_string, no_of_bits_to_return) تكرارًا على النحو الآتي: بالنسبة إلى counter = 1, 2, ...، احسب H(counter || no_of_bits || input_string) وادمج المخرجات حتى إنتاج عدد كافٍ من البتات. تتيح هذه العملية تمديد مدخلات الإنتروبيا القصيرة إلى بذور بحجم الحالة. وأثناء Generate، تحسب دالة المخرجات W = H(0x03 || V)، حيث تميّز البادئة 0x03 هذا الاستخدام عن استخدامات الهاش الأخرى. وتعمل حلقة الإخراج كما يلي: data = H(0x01 || V)؛ ثم V = V + 1؛ ويُكرّر ذلك لإنتاج مزيد من المخرجات. وبعد التوليد، يُحدّث V كما يلي: V = V + H(0x03 || V) + C + reseed_counter. ويمنع فصل المجالات باستخدام بايتات البادئة (0x01 و0x03) الخلط بين مخرجات مرحلة التوليد ومرحلة تحديث الحالة.

تُعدّ دالة Update في HMAC_DRBG جوهر جميع عمليات انتقال الحالة. تنفّذ Update(provided_data, K, V): K = HMAC(K, V || 0x00 || provided_data); V = HMAC(K, V). وإذا لم تكن provided_data فارغة، تُنفّذ الخطوات التالية: K = HMAC(K, V || 0x01 || provided_data); V = HMAC(K, V). ويضمن هذا التحديث المكوّن من خطوتين اعتماد كل من المفتاح والقيمة الجديدين على الحالة السابقة وأي إنتروبيا جديدة. وفي Generate، تُكرّر V = HMAC(K, V) وتُضاف النتائج إلى المخرجات حتى إنتاج عدد كافٍ من البتات، ثم تُستدعى Update مع additional_input لتطوير الحالة. ويستند أمان HMAC_DRBG إلى افتراض أن HMAC دالة عشوائية زائفة PRF آمنة؛ فإذا عجز الخصم عن تمييز مخرجات HMAC من العشوائية، عجز كذلك عن تمييز مخرجات DRBG من العشوائية.

يستخدم CTR_DRBG ‏Block_Cipher_df (دالة الاشتقاق) لمعالجة مادة البذرة وتحويلها إلى صيغة مفتاح/عداد. تستخدم Block_Cipher_df(input_string, no_of_bits) بنية BCC (Block Cipher Chaining)، فتطبّق AES-CBC تكراريًا على أجزاء الإدخال لإنتاج مخرجات بالطول المطلوب. وتلزم دالة الاشتقاق للتعامل مع مدخلات الإنتروبيا متفاوتة الطول ولتوفير فصل المجالات. ويكون CTR_DRBG من دون دالة اشتقاق (وهو مسموح به لاختبارات FIPS عند استخدام مدخلات منسّقة بدقة) أسرع، لكنه أكثر حساسية لمتطلبات تنسيق الإدخال. وتعمل حلقة Generate كما يلي: temp = E(K, V)؛ ثم V = V + 1؛ وتُضاف temp إلى المخرجات. أما Update فتعمل كما يلي: K || V = Block_Cipher_df(V || additional_input, seedlen)؛ ثم يُطبّق XOR على المفتاح الحالي.

يختلف الأداء اختلافًا كبيرًا بين أنواع DRBG. فعلى وحدة معالجة مركزية حديثة من نوع x86_64 تدعم AES-NI، يحقق CTR_DRBG (AES-256) سرعة تقارب 5–10 GB/s من المخرجات شبه العشوائية؛ إذ تجعل تعليمة AES-NI حساب AES شبه مجاني. ويحقق HMAC_DRBG (SHA-256) نحو 200–400 MB/s؛ فـ SHA-256 سريع، لكنه لا يستفيد من تسريع عتادي بالدرجة نفسها. أما Hash_DRBG (SHA-256) فيحقق نحو 100–300 MB/s. وعند توليد كميات كبيرة من المفاتيح أو استبدال الشفرات التدفقية، يكون CTR_DRBG أسرع بكثير. أما في الاستخدامات منخفضة معدل النقل، مثل توليد مفاتيح الجلسات واشتقاق nonces، فالفارق في الأداء غير مهم. ولهذا السبب يستخدم OpenSSL 3.0 ‏CTR_DRBG (AES-256) افتراضيًا.

عند التهيئة، تقبل DRBGs الثلاثة اختياريًا personalization_string، الذي يُمزج مع مدخل الإنتروبيا لجعل مثيل DRBG فريدًا. ويمنع ذلك مثيلين من DRBG جرى إنشاؤهما في الوقت نفسه وبالإنتروبيا نفسها من إنتاج المخرجات ذاتها؛ إذ يختلف مسارهما استنادًا إلى personalization_string. وتشمل سلاسل التخصيص الموصى بها: معرّف التطبيق + معرّف العملية + معرّف الخيط + الطابع الزمني + معرّف العتاد. وحتى إذا تلقت VM إنتروبيا متطابقة، كما قد يحدث بسبب مشكلة لقطة VM السحابية، فإن اختلاف سلاسل التخصيص يضمن اختلاف تدفقي DRBG. ويوصي NIST SP 800-90C باستخدام personalization string دائمًا. ويؤدي nonce غرضًا مشابهًا؛ فهو قيمة قصيرة وفريدة تضمن ألا تبدأ تهيئتان في الحالة نفسها.

تدعم DRBGs الثلاثة جميعًا معامل additional_input في استدعاءات Generate. ويتيح ذلك للمستدعي حقن سياق أو إنتروبيا إضافية في استدعاء توليد واحد من دون إجراء إعادة تزويد كاملة بالبذرة. ومن الاستخدامات: (1) حقن إنتروبيا لكل طلب من مصدر إنتروبيا ثانوي؛ (2) توفير سياق على مستوى التطبيق (معرّف الطلب والطابع الزمني) لربط القيم المولّدة باستخدامها؛ (3) توفير مقاومة تنبؤ اختيارية عبر حقن إنتروبيا جديدة من نظام التشغيل. ويُدمج additional_input في حالة DRBG قبل توليد المخرجات. وإذا كان additional_input يوفر إنتروبيا حقيقية، فإنه يحسّن الأمان من دون الحاجة إلى إعادة تزويد رسمية بالبذرة، وهي عملية تتضمن واجهة مصدر الإنتروبيا والتكلفة الإضافية المرتبطة بها.

بعد إلغاء تهيئة DRBG (أو عند الانتقال إلى مثيل جديد)، يجب تصفير الحالة الداخلية تصفيرًا آمنًا. ويجب الكتابة فوق الحالة V وC (في Hash_DRBG)، وK وV (في HMAC/CTR_DRBG)، وجميع متغيرات العمل الوسيطة، باستخدام أصفار. ويُسمى ذلك التصفير الصريح، وهو إلزامي في وحدات FIPS 140-3. وفي لغة C، استخدم explicit_bzero() أو SecureZeroMemory()؛ إذ قد يزيل المترجم عملية memset المحسّنة باعتبارها تحسينًا لتخزين ميت، مما يترك مادة المفتاح في الذاكرة. وتتعامل حزمة zeroize في Rust والحلول المماثلة الخاصة بكل لغة مع ذلك بطريقة قابلة للنقل. ويكتسب الإتلاف الآمن للمفاتيح أهمية في السياقات التي قد تكشف فيها تفريغات الذاكرة أو هجمات الإقلاع البارد أو أدوات فحص العمليات عن الحالة المتبقية.

يوفر NIST متجهات اختبار برنامج التحقق من الخوارزميات التشفيرية (CAVP) لجميع DRBGs وفق SP 800-90A. وتشمل أنواع الاختبارات: (1) اختبارات الإجابة المعروفة (KATs): عند إعطاء مدخل إنتروبيا وnonce وسلسلة تخصيص ثابتة، يُتحقق من مطابقة المخرجات المولّدة للقيم المحسوبة مسبقًا. (2) اختبارات إعادة التزويد بالبذرة: يُتحقق من حالة DRBG بعد عملية إعادة التزويد بالبذرة. (3) اختبارات PR (مقاومة التنبؤ): يُتحقق من أن طلب prediction_resistance=true ينتج المخرجات الصحيحة بعد حقن إنتروبيا جديدة. ويلزم التحقق من CAVP لتقديم طلب FIPS 140-3. وتضمّن المكتبات مفتوحة المصدر (OpenSSL وmbedTLS) متجهات اختبار CAVP في مجموعات اختبارات الانحدار الخاصة بها لاكتشاف التراجعات في تطبيقات DRBG.

تواجه تطبيقات DRBG مخاطر دقيقة للقنوات الجانبية تتجاوز نموذج الأمان الخوارزمي. فقد تسرّب هجمات توقيت ذاكرة التخزين المؤقت على AES (في CTR_DRBG من دون AES-NI) مادة مفاتيح الجولات؛ ويزيل AES-NI هذا الخطر عبر الحساب داخل السجلات ومن دون عمليات بحث في الجداول. ويستخدم HMAC_DRBG دالة HMAC داخليًا، وتكون ذات زمن ثابت إذا كانت SHA-256 الأساسية ذات زمن ثابت؛ ويُعدّ SHA-256 عمومًا ذا زمن ثابت لأنه لا يحتوي على فروع تعتمد على البيانات. وتشكل القنوات الجانبية الفيزيائية، مثل تحليل الطاقة والإشعاع الكهرومغناطيسي، مصدر قلق للأجهزة العتادية التي تنتج DRBG، مثل البطاقات الذكية وأجهزة IoT، ويُعالج ذلك باستخدام تطبيقات تعتمد على التمويه. أما هجوم استعادة حالة DRBG، فإذا تمكن الخصم من قراءة حالة DRBG عبر ثغرة تكشف الذاكرة على نمط Heartbleed، فستُخترق جميع المخرجات المستقبلية إلى أن تتم إعادة تزويد DRBG بالبذرة باستخدام إنتروبيا جديدة.

إذا كُشفَت حالة DRBG، مثلًا عبر ثغرة تكشف الذاكرة، فتتطلب استعادتها ما يلي: (1) اكتشاف الاختراق؛ فتسريبات حالة DRBG ليست واضحة بذاتها، ولذلك يلزم رصد خارجي أو إجراء فحوصات سلامة. (2) إعادة تزويد DRBG بالبذرة باستخدام إنتروبيا جديدة من مصدر موثوق لم يشارك في الاختراق. (3) إعادة إنشاء جميع المواد التشفيرية المشتقة من DRBG المخترق، بما في ذلك مفاتيح الجلسات ومفاتيح التوقيع التي جرى توليدها منذ آخر إعادة تزويد سليمة بالبذرة. (4) في التطبيقات البرمجية، توفر إعادة تشغيل العملية تهيئة نظيفة لـ DRBG. ويوصي SP 800-90C بمصادر إنتروبيا متسلسلة؛ فإذا اختُرق أحد المصادر، يظل الجمع بينها آمنًا ما دام المصدر الآخر يوفر إنتروبيا حقيقية.

يستخدم Hash_DRBG التجزئة التكرارية مع Hash_df للاشتقاق، وينتج المخرجات عبر حلقات H(0x01 || V). ويستخدم HMAC_DRBG ‏HMAC بوصفه PRF، مع دالة Update من خطوتين (المفتاح ثم القيمة) توفر اختزالًا أمنيًا واضحًا. أما CTR_DRBG فيستخدم AES في نمط العدّاد مع Block_Cipher_df، ويحقق سرعة تبلغ 5–10 GB/s على العتاد الذي يدعم AES-NI. وتقبل جميع الآليات personalization_string عند التهيئة لضمان فرادة المثيل، وadditional_input في كل عملية generate لربط السياق. وتتحقق متجهات اختبار CAVP من صحة التطبيقات. ويجب تصفير الحالة تصفيرًا آمنًا بعد الاستخدام. وتتطلب الاستفادة من حالة مخترقة إعادة تزويدها بالبذرة باستخدام إنتروبيا جديدة وإعادة إنشاء المفاتيح للمواد المشتقة.