هجمات إعادة الإرسال وثغرات إعادة استخدام Nonce

يضمن nonce، أي الرقم المستخدم مرة واحدة، أن يؤدي تشفير الرسالة ذاتها مرتين إلى إنتاج نصين مشفرين مختلفين. وهذا ضروري للأمان الدلالي، إذ لا يحصل المهاجم الذي يراقب عدة نصوص مشفرة على أي معلومات توضح ما إذا كانت تشفّر نصوصًا صريحة متماثلة أم مختلفة. وفي الشفرات الانسيابية وشفرات الكتل المعتمدة على وضع CTR، يُستخدم nonce لتهيئة توليد دفق المفاتيح، ولذلك فهو مهم للغاية للأمان.

في AES-GCM، يُستخدم nonce بطول 96 بت لتهيئة عداد لتشفير وضع CTR، كما يساهم في حساب مصادقة GHASH. وتُشتق قيمة العداد لكل كتلة AES بزيادتها انطلاقًا من nonce. فإذا استخدمت عمليتا تشفير nonce والمفتاح نفسيهما، فستولدان دفق المفاتيح نفسه، مما يجعل XOR للنصين المشفرين مساويًا لـ XOR للنصين الصريحين.

بالنسبة إلى نصين مشفرين في GCM شُفِّرا باستخدام زوج (المفتاح، nonce) نفسه، يساوي XOR بينهما XOR بين النصين الصريحين. وإذا عرف المهاجم أحد النصين الصريحين، كما يحدث عادةً في سيناريوهات النص الصريح المختار، فسيستعيد النص الآخر فورًا. وحتى من دون معرفة نص صريح، يكشف XOR للنصوص المشفرة أنماط اللغة ويمكن مهاجمته باستخدام تقنيات crib-dragging. وهذا أحد أكثر أنماط إساءة استخدام التشفير كارثية.

تترتب على إعادة استخدام nonce في GCM نتيجة كارثية إضافية تتجاوز استعادة النص الصريح. إذ يُشتق مفتاح مصادقة GHASH ‏H من مفتاح التشفير وحده. وإذا اشتركت رسالتان في زوج (المفتاح، nonce) نفسه، فيستطيع المهاجم حل معادلات متعددة الحدود لاستعادة ‏H. ومع معرفة ‏H، يستطيع المهاجم تزوير علامات مصادقة GCM صالحة لنصوص مشفرة عشوائية، مما يكسر سلامة الرسائل بالكامل.

استفاد TLS 1.3 من مخاطر إعادة استخدام nonce في تطبيقات TLS 1.2. إذ ينشئ TLS 1.3 قيم nonce لـ GCM عبر إجراء XOR بين IV الكتابة ذي 12 بايتًا، المشتق من المصافحة، ورقم التسلسل ذي 8 بايتات، بعد تمديده بالأصفار إلى 12 بايتًا. وبما أن أرقام التسلسل تزداد مع كل سجل، فإن كل سجل يستخدم nonce فريدًا. ويزيل ذلك مخاطر توليد nonce عشوائيًا، مع ضمان فرادة nonce من خلال آلية رقم التسلسل.

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

يوفر تضمين طابع زمني في الرسائل الموثقة حماية من إعادة التشغيل. فلا يقبل المستقبل الرسائل إلا ضمن نافذة زمنية قصيرة، مثل 5 دقائق من الطابع الزمني المزعوم. وتقع الرسالة المُعاد تشغيلها بعد ساعات خارج النافذة، فيرفضها المستقبل. ويجب توثيق الطابع الزمني، أي وضعه داخل HMAC أو ضمن البيانات المرتبطة في AEAD، لمنع المهاجم من تعديله بحيث يبدو حديثًا.

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

بالنسبة إلى AES-GCM، تتمثل الاستراتيجية الموصى بها لتوليد nonce عشوائي في استخدام 96 بتًا من مولد أرقام شبه عشوائية آمن تشفيريًا (CSPRNG). ومع استخدام nonce عشوائي بطول 96 بتًا، يصل احتمال التصادم وفق حد عيد الميلاد إلى 2^-32 بعد 2^32 عملية تشفير، أي نحو 4 مليارات عملية. وبالنسبة إلى التطبيقات ذات الحجم الكبير، انتقل إلى nonce قائم على عداد أو استخدم AEAD مختلفًا، مثل XChaCha20-Poly1305 ذي nonce بطول 192 بتًا، لتمديد الحد الآمن.

تتجنب قيم nonce الحتمية القائمة على عداد مشكلات حد عيد الميلاد، لكنها تتطلب إدارة دقيقة للحالة. ويجب حفظ العداد عبر عمليات إعادة تشغيل التطبيق؛ فالعداد الذي يُعاد ضبطه إلى الصفر عند إعادة التشغيل ينشئ فورًا إعادة استخدام لـ nonce مع المفتاح نفسه. ويجب تحديث العداد ذريًا قبل استخدام nonce، وليس بعده. وفي الأنظمة الموزعة، تتطلب قيم nonce القائمة على عداد تنسيقًا لمنع عقدتين من استخدام قيمة العداد نفسها.

يوسّع XChaCha20-Poly1305 قيمة nonce في ChaCha20-Poly1305 من 96 إلى 192 بتًا. ومع استخدام nonce عشوائي بطول 192 بتًا، يصبح احتمال التصادم وفق حد عيد الميلاد ضئيلًا للغاية حتى بعد 2^96 عملية تشفير، وهو عدد فلكي من الرسائل. ويجعل ذلك توليد nonce عشوائيًا آمنًا من دون مخاوف عملية مرتبطة بحد عيد الميلاد. وتستخدم crypto_secretbox في libsodium ‏(XSalsa20-Poly1305) قيم nonce بطول 192 بتًا للسبب نفسه.

إذا أُنتج نصان مشفران في GCM باستخدام المفتاح وnonce نفسيهما، فما الذي يمكن للمهاجم استعادته؟

مراجعة إعادة استخدام nonce: تضمن قيم nonce فرادة النصوص المشفرة، وتكشف إعادة استخدام nonce في GCM عن XOR للنصوص الصريحة وتكسر المصادقة عبر استعادة ‏H، ويستخدم TLS 1.3 عملية XOR بين رقم التسلسل وIV لضمان فرادة nonce، وتعيد هجمات إعادة التشغيل إرسال رسائل صالحة من دون تعديل، وتمنع الطوابع الزمنية وأرقام التسلسل في الرسائل الموثقة إعادة التشغيل، فاستخدم قيم nonce عشوائية بطول 96 بتًا في GCM مع الانتباه إلى حدود عيد الميلاد، أو استخدم XChaCha20 لمساحة أكبر من قيم nonce العشوائية.