وضع SIV: تشفير AEAD مقاوم لسوء استخدام nonce

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

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

صُمم وضع Synthetic IV ‏(SIV)، المعرَّف في RFC 5297، للقضاء على ثغرات إعادة استخدام nonce. فبدلًا من اشتراط nonce عشوائي أو قائم على عداد، يشتق SIV قيمة IV اصطناعيًا من النص الصريح نفسه باستخدام دالة شبه عشوائية، مما يجعله حتميًا ومقاومًا لسوء استخدام nonce.

في SIV، تُحسب قيمة nonce، التي تُسمى IV الاصطناعية، بالصيغة SIV = PRF(key, plaintext, associated_data). ثم تُستخدم قيمة IV هذه بوصفها العداد لتشفير وضع CTR. وبما أن IV مشتقة من النص الصريح، فإن تشفير النص الصريح نفسه ينتج دائمًا النص المشفر نفسه.

إذا أُعيد استخدام nonce في SIV بسبب تشفير النص الصريح نفسه مرتين، فلن يعرف المراقب سوى أنه أُرسلت رسالتان متطابقتان. ويظل محتوى النص الصريح نفسه مخفيًا. ويمثل ذلك تحسنًا كبيرًا مقارنةً بـ AEAD القائم على CTR، حيث تكشف إعادة استخدام nonce عن XOR للنص الصريح.

يستخدم AES-SIV (RFC 5297) الدالة S2V، وهي PRF متسلسلة تعتمد على AES-CMAC، لإنشاء IV اصطناعي، ثم يجري التشفير باستخدام AES-CTR المزوّد بمفتاح فرعي ثانٍ. ويتطلب ذلك مفتاحَي AES، مما يجعل إدارة المفاتيح أكثر تعقيدًا قليلًا من أوضاع AEAD ذات المفتاح الواحد.

يُعد AES-GCM-SIV (RFC 8452) نمط AEAD أكثر كفاءة ومقاومًا لإساءة استخدام nonce، وقد صُمم للجمع بين أداء GCM وأمان شبيه بـ SIV. ويشتق مفاتيح فرعية خاصة بكل رسالة من nonce، ويستخدم مُصدِّق Polyval، محققًا أداءً أفضل من AES-SIV مع الحفاظ على مقاومة إساءة استخدام nonce.

يتطلب SIV المرور على البيانات مرتين: مرة لحساب IV الاصطناعي، ومرة لإجراء التشفير. ويؤدي ذلك تقريبًا إلى مضاعفة الكلفة الحسابية مقارنةً بأوضاع AEAD ذات المرور الواحد مثل AES-GCM. ويجب أخذ هذه الكلفة الإضافية في الاعتبار في التطبيقات الحساسة لزمن الاستجابة أو ذات معدل النقل المرتفع.

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

تُعد الخدمات المصغرة عديمة الحالة، التي لا تستطيع تنسيق حالة nonce عبر النسخ المتماثلة، مرشحةً مثالية لنمط SIV. فبدلًا من المخاطرة بإعادة استخدام nonce عن طريق عدّاد عام، يوفر SIV الأمان تلقائيًا. ويستخدم تغليف المفاتيح (RFC 3394) أيضًا مبادئ SIV لتشفير المفاتيح حتميًا.

يتوفر AES-SIV في مكتبات التشفير الرئيسية، بما فيها libsodium (باسم crypto_aead_aes256gcm_siv في الإصدارات الحديثة) وGoogle Tink. ويدعم BoringSSL ومكتبة Go القياسية AES-GCM-SIV. وعندما تكون إدارة nonce صعبة، تكون هذه الخيارات الافتراضية أكثر أمانًا من AES-GCM القياسي.

ماذا يحدث عند استخدام المفتاح نفسه لتشفير النص الصريح نفسه مرتين باستخدام AES-SIV؟

يلغي نمط SIV الكوارث الناتجة عن إعادة استخدام nonce، وذلك باشتقاق IV من النص الصريح نفسه. ولا تكشف إعادة استخدام nonce إلا أن رسائل متطابقة أُرسلت، وليس محتواها. ويوفر AES-GCM-SIV (RFC 8452) مقاومة فعالة لإساءة استخدام nonce في التطبيقات الحديثة التي تحتاج إلى تشفير عديم الحالة أو حتمي.