AES-256-GCM: معيار التشفير الموثق الذي يؤمّن ملفات آيفون الخاصة بك

TL;DR

AES-256-GCM هو خوارزمية تشفير موثق يقوم بتشفير البيانات والتحقق من سلامتها باستخدام مفتاح واحد ورقم فريد (nonce) لكل رسالة. تم تعريفه بمعايير NIST، ومدعوم بتسريع عتادي على آيفونات الحديثة، وتستخدمه TLS 1.3 وWireGuard وSignal. تطبق AppVault AES-256-GCM برقم فريد 96 بت لكل ملف، ومفتاح مستخلص من PBKDF2 ملفوف عبر المعالج الآمن، وبدون أي اتصالات شبكية.

AES-256-GCM ليس خوارزمية واحدة. إنه مزيج من معيارين: معيار التشفير المتقدم (AES) بمفتاح 256 بت، ووضع غالويس/العداد (GCM) للتشغيل. يشكلان معاً نظام تشفير موثق يوفر السرية والتحقق من السلامة في خطوة واحدة. إنه الشفرة الافتراضية في TLS 1.3 وWireGuard وSignal وتشفير الملفات على مستوى نظام iOS. فهم كيف يعمل أمر مهم لأن معظم فشل الأمان في AES-256-GCM يأتي من أخطاء في التنفيذ، وليس من كسر الخوارزمية.

للحصول على مقدمة غير تقنية حول خوارزمية الكتلة الأساسية — ماذا يعني “مفتاح 256 بت”، لماذا مساحة المفاتيح غير قابلة للكسر بالقوة الغاشمة، كيف تم اختيار AES من قبل NIST في 2001 — اقرأ أولاً نظرة عامة بلغة بسيطة ما هو تشفير AES-256؟. هذه المقالة تتعمق أكثر في وضع GCM تحديداً.

خوارزمية الكتلة: AES-256

AES هي خوارزمية كتلة متناظرة معيارية من NIST في FIPS 197. تعمل على كتل بحجم 128 بت وتدعم أحجام مفاتيح 128 و192 و256 بت. يستخدم AES-256 مفتاحاً بطول 256 بت وينفذ 14 دورة من عمليات الاستبدال والتبديل. كل دورة تطبق أربعة تحويلات: SubBytes (استبدال غير خطي عبر S-box)، ShiftRows (تبديل البايتات)، MixColumns (ضرب مصفوفة في حقل GF(2^8))، وAddRoundKey (XOR مع مفتاح الدورة المستخلص من المفتاح الرئيسي).

هامش الأمان لـ AES-256 عالٍ. أفضل هجمات التحليل الشيفري المعروفة هي على متغيرات ذات دورات مخفضة (مثل AES-128 بدورات 7) أو على نماذج المفاتيح ذات الصلة التي لا تنطبق على الاستخدام الواقعي. بالنسبة لـ AES-256 الكامل بـ14 دورة، لا يوجد هجوم عملي يقلل حجم المفتاح الفعال عن 256 بت. هذا هو السبب في أن AES-256 معتمد للبيانات فائقة السرية من قبل وكالة الأمن القومي الأمريكية.

AES-256 مدعوم بتسريع عتادي على جميع المعالجات الحديثة تقريباً. تشتمل معالجات إنتل وAMD على تعليمات AES-NI. تشتمل أبل سيليكون (رقاقات السلسلة M وA) على ملحقات التشفير ARM التي تسرع عمليات AES وSHA وGCM. على آيفون، يكتمل تشفير ملف بحجم 10 ميجابايت بـ AES-256 في أجزاء من الثانية.

الوضع: غالويس/العداد (GCM)

خوارزمية الكتلة تشفر كتلة واحدة فقط في كل مرة. لتشفير رسائل أطول من 128 بت، تحتاج إلى وضع تشغيل. GCM، المحدد في NIST SP 800-38D، هو وضع تشفير موثق يجمع بين متغير وضع العداد للتشفير ودالة تجزئة شاملة (GHASH) للمصادقة. نفس البناء مسجل كوحدة AEAD في IETF RFC 5116.

يعمل GCM على مرحلتين. أولاً، يتم تشفير النص العادي باستخدام AES في وضع العداد: يتم زيادة عداد بطول 128 بت لكل كتلة، وتشفيره باستخدام AES، ثم إجراء XOR مع النص العادي لإنتاج النص المشفر. القيمة الأولية للعداد مشتقة من nonce (رقم مستخدم مرة واحدة) بالإضافة إلى عداد يبدأ من 1. ثانياً، يتم إدخال النص المشفر والبيانات المرتبطة (بيانات وصفية يجب توثيقها ولكن لا يتم تشفيرها) إلى GHASH، وهو تقييم متعدد الحدود في GF(2^128). ثم يتم تشفير مخرجات GHASH باستخدام AES لإنتاج علامة المصادقة.

النتيجة هي مخرج واحد: نص مشفر بالإضافة إلى علامة مصادقة بطول 128 بت (الطول الافتراضي، يمكن تقصيره). يقوم المستقبل بفك التشفير عن طريق إعادة حساب العلامة ومقارنتها. إذا تطابقت العلامة، تكون البيانات موثقة. إذا لم تتطابق، يجب على المستقبل رفض البيانات.

GCM قابل للتنفيذ بالتوازي. وضع العداد يسمح بتشفير كتل متعددة في وقت واحد، وهذا هو السبب في أن التسريع العتادي يمكن أن يحقق إنتاجية عالية. على آيفون مع ملحقات ARM Crypto Extensions، يمكن لـ AES-256-GCM تشفير عدة جيجابت في الثانية.

انضباط Nonce: نقطة الفشل الأكثر شيوعاً

يتطلب AES-256-GCM nonce. المواصفات تحدد nonce بطول 96 بت. يجب أن يكون nonce فريداً لكل عملية تشفير تتم بنفس المفتاح. إعادة استخدام nonce مع نفس المفتاح يسمح للمهاجم باستعادة مفتاح المصادقة GHASH (H) ومن ثم تزوير أي رسالة.

الرياضيات لا ترحم: إذا شارك نصان مشفران نفس nonce والمفتاح، فإن عملية XOR لمخرجات GHASH تكشف عن XOR للنصين العاديين. من هناك، يمكن للمهاجم استعادة H وإنتاج علامات صالحة لأي نص مشفر. هذا ليس هجوماً نظرياً. تم استغلاله عملياً، وأشهرها في ورقة “Nonce-Disrespecting Adversaries” عام 2015 التي وجدت ثغرات إعادة استخدام nonce في عدة تطبيقات TLS.

التخفيف الصحيح هو عدم إعادة استخدام nonce أبداً تحت نفس المفتاح. عملياً، هذا يعني إما توليد nonce عشوائي (96 بت يعطي احتمالات 2^96، ولكن حد عيد الميلاد يعني أنه لا يجب عليك تشفير أكثر من 2^32 رسالة باستخدام nonces عشوائي للحفاظ على احتمال التصادم ضئيلاً) أو استخدام عداد حتمي مضمون الفريدة لكل رسالة.

تستخدم AppVault nonce فريداً 96 بت لكل ملف. يتم توليد nonce باستخدام مولد أرقام عشوائي آمن تشفيرياً (SecRandomCopyBytes في iOS) ويتم تخزينه بجانب النص المشفر. نظراً لأن كل ملف يحصل على nonce الخاص به، والمفتاح مشتق لكل تثبيت وملفوف بواسطة المعالج الآمن، فإن خطر إعادة استخدام nonce يتم القضاء عليه.

التسريع العتادي: لماذا هو مهم

AES-256-GCM مكلف حسابياً في البرمجيات. ضرب GHASH في GF(2^128) مكلف بشكل خاص بدون دعم عتادي. تشتمل المعالجات الحديثة على تعليمات مخصصة تنفذ دورات AES وعمليات GHASH في دورة واحدة.

على آيفون، تشتمل ملحقات ARM Crypto Extensions على:

• تعليمات AES (AESE، AESD، AESMC، AESIMC) التي تنفذ دورة واحدة من تشفير أو فك تشفير AES.
• تعليمات GHASH (PMULL/PMULL2 للضرب متعدد الحدود) التي تسرع حساب GHASH.

المعالج الآمن في أبل سيليكون يتضمن محرك AES مخصصاً يمكنه تشفير البيانات دون كشف المفتاح للمعالج الرئيسي. تستخدم AppVault المعالج الآمن لتغليف مفتاح تشفير الملف، مما يضمن أنه حتى إذا تم اختراق المعالج الرئيسي، يبقى المفتاح محمياً.

بدون التسريع العتادي، سيكون AES-256-GCM بطيئاً جداً للتطبيقات الفورية مثل مصافحة TLS أو بث الفيديو. معه، يكون الحمل إضافياً ضئيلاً.

أين يُستخدم AES-256-GCM

AES-256-GCM هو مجموعة الشفرات الافتراضية في TLS 1.3 (TLS_AES_256_GCM_SHA384). كل اتصال HTTPS يستخدم TLS 1.3 يعتمد عليه. WireGuard، بروتوكول VPN الحديث، يستخدم AES-256-GCM (أو ChaCha20-Poly1305 على الأجهزة بدون AES عتادي). Signal، تطبيق المراسلة المشفرة، يستخدم AES-256-GCM لتشفير ملفات الوسائط. iOS يستخدم AES-256-GCM لتشفير الملفات على مستوى حماية البيانات.

انتشار AES-256-GCM ليس صدفة. إنه معيار NIST، مدعوم بتسريع عتادي، ومفهوم جيداً من قبل مجتمع التشفير. إنه الخيار الآمن الافتراضي لأي تطبيق يحتاج إلى تشفير موثق.

مقارنة مع أوضاع التشفير الموثقة الأخرى

AES-256-GCM ليس وضع AEAD الوحيد. ChaCha20-Poly1305 بديل شائع، خاصة على الأجهزة بدون تسريع AES عتادي. ChaCha20 هي شفرة تيار، وليست شفرة كتلية، وPoly1305 هو تجزئة متعددة الحدود مشابهة لـ GHASH. ChaCha20-Poly1305 أسرع برمجياً من AES-256-GCM في البرمجيات، ولكن على العتاد مع AES-NI، AES-256-GCM أسرع.

AES-256-CCM (عداد مع CBC-MAC) هو وضع AEAD آخر معياري من NIST، لكنه غير قابل للتنفيذ بالتوازي وأبطأ من GCM. يُستخدم CCM في بعض بروتوكولات إنترنت الأشياء واللاسلكي، لكن TLS ومعظم التطبيقات الحديثة تفضل GCM.

AES-256-GCM-SIV هو متغير مقاوم لإساءة استخدام nonce يتدهور بشكل مهذب إذا تم إعادة استخدام nonce (يكشف فقط أن رسالتين متساويتين، وليس النص العادي). إنه أبطأ من GCM القياسي وأقل انتشاراً.

معظم التطبيقات، AES-256-GCM هو الخيار الصحيح. إنه سريع، قياسي، وآمن عند تنفيذه بشكل صحيح.

كيف تنفذ AppVault AES-256-GCM

تستخدم AppVault AES-256-GCM لكل ملف مخزن في الخزنة. يتبع التنفيذ هذه الخطوات:

1. استخلاص المفتاح. يتم تحويل قفل النمط الخاص بالمستخدم إلى مفتاح رئيسي بطول 256 بت باستخدام PBKDF2-SHA256 مع 600,000 تكرار وملح (salt) بحجم 128 بت لكل تثبيت. هذا المفتاح لا يُستخدم أبداً مباشرة للتشفير.
2. تغليف المعالج الآمن. يتم إرسال المفتاح الرئيسي إلى المعالج الآمن، الذي يولد مفتاحاً جديداً (مفتاح التغليف) لا يغادر الشريحة أبداً. يقوم المعالج الآمن بتشفير المفتاح الرئيسي باستخدام مفتاح التغليف ويعيد المفتاح المغلف إلى المعالج الرئيسي. ثم يتم مسح المفتاح الرئيسي النص العادي من الذاكرة.
3. تشفير الملف. لكل ملف، يتم توليد nonce جديد بطول 96 بت باستخدام SecRandomCopyBytes. يتم فك تغليف المفتاح المغلف داخل المعالج الآمن واستخدامه لتشفير الملف باستخدام AES-256-GCM. يتم كتابة النص المشفر و nonce إلى التخزين. يتم إلحاق علامة المصادقة بالنص المشفر.
4. تشفير الفهرس. حتى قائمة الملفات (الأسماء، التواريخ، الأحجام) مشفرة بـ AES-256-GCM تحت مفتاح منفصل مشتق من نفس المفتاح الرئيسي. هذا يعني أن المهاجم الذي لديه وصول خام إلى الجهاز لا يمكنه تحديد عدد الملفات الموجودة.

النتيجة هي أنه لا يوجد ملفان ينتجان نفس النص المشفر، حتى لو احتويا على نص عادي متطابق. المعالج الآمن يضمن أن مفتاح التشفير لا يتعرض أبداً لنظام التشغيل الرئيسي. ونظراً لأن AppVault لا تجري أي اتصالات شبكية، فلا يوجد خادم يمكن اختراقه لتسريب المفاتيح أو النصوص المشفرة.

قيود AES-256-GCM

AES-256-GCM لا يحمي من كل شيء. إنه عرضة لهجمات القناة الجانبية إذا كشف التنفيذ عن التوقيت أو استهلاك الطاقة. حساب GHASH حساس بشكل خاص لهجمات التوقيت؛ التطبيقات ذات الوقت الثابت مطلوبة. توفر مكتبة CoreCrypto من أبل تنفيذ AES-256-GCM بزمن ثابت، وتستخدم AppVault تلك المكتبة.

AES-256-GCM لا يوفر سرية تامة. إذا تم اختراق المفتاح، يمكن فك تشفير جميع النصوص المشفرة السابقة. يتم تحقيق السرية التامة على مستوى البروتوكول (مثل TLS 1.3 الذي يستخدم تبادل مفاتيح Diffie-Hellman المؤقت) وليست خاصية للخوارزمية نفسها. تخفف AppVault من هذا عن طريق إبقاء المفتاح على الجهاز وعدم نقله أبداً.

AES-256-GCM ليس آمناً ضد الحواسيب الكمومية. خوارزمية جروفر تقلل حجم المفتاح الفعال لـ AES-256 من 256 بت إلى 128 بت. حاسوب كمومي كبير بما يكفي يمكنه كسره. ومع ذلك، مثل هذا الحاسوب الكمومي لا يوجد حالياً ومن غير المتوقع خلال العقد القادم. للأسرار طويلة الأجل، يتم معايرة تشفيرات ما بعد الكم مثل CRYSTALS-Kyber.

AES-256-GCM لا يحمي من تحليل الشفرة بالقوة الغاشمة البشرية أو الاستيلاء المادي على الجهاز. إذا كان لدى المهاجم وصول مادي إلى آيفون الخاص بك ويمكنه إجبارك على فتحه، فلا يمكن لأي تشفير حماية ملفاتك. يفترض نموذج التهديد لـ AppVault أن الجهاز تحت سيطرتك.

لماذا اختارت AppVault AES-256-GCM

اختارت AppVault AES-256-GCM لأنه خوارزمية التشفير الموثق الأكثر انتشاراً مع تسريع عتادي على كل آيفون حديث. إنه معياري، مراجع من الأقران، وموثوق من قبل أكبر بروتوكولات الأمان في العالم. يسمح لـ AppVault بتشفير الملفات بسرعة دون استنزاف البطارية، والتحقق من سلامته يضمن عدم العبث بالملفات المخزنة.

البديل، ChaCha20-Poly1305، آمن أيضاً وتستخدمه AppVault لبعض العمليات حيث لا يتوفر AES عتادي (على الأجهزة الأقدم مثلاً). ولكن لتشفير الملفات على iOS، AES-256-GCM هو الخيار الطبيعي.

كل ملف في AppVault مشفر بـ AES-256-GCM، و nonce فريد، ومفتاح مشتق من قفل النمط الخاص بك وملفوف بواسطة المعالج الآمن. المجموعة التشفيرية الكاملة موثقة على صفحة تشفير AES-256-GCM، مع استشهادات بـ NIST FIPS 197 وNIST SP 800-38D ودليل أمن منصة أبل. صفحة نموذج التهديد تشرح ما تدافع عنه هذه البنية وما لا تدافع عنه. صفحة بنية المعرفة الصفرية تشرح لماذا لا ترى AppVault بياناتك أبداً.