حالة ما بعد التشفير الكمي

في أواخر شهر مارس من عام 2026، أعلنت Google عن جدول زمني لعام 2029 لترحيل التشفير ما بعد الكمي (PQC). ويشير هذا الإعلان أيضًا إلى حدوث تغيير في الأولويات. تركزت أعمال تنفيذ PQC إلى حد كبير على التبادلات الرئيسية، مما يخفف من هجمات Harvest-Now-Decrypt-Later (HNDL). كان الهدف هو استخدام ML-KEM أثناء مفاوضات الجلسة (على سبيل المثال، الحصول على TLS لاستخدام X25519MLKEM768). تقوم Google الآن بإعطاء الأولوية لـ PQC في خدمات المصادقة، مما يعني الحصول على إحدى خوارزميات التوقيع الرقمي PQC المستخدمة (مثل ML-DSA أو SLH-DSA). يجب أن تتم عمليات ترحيل خوارزمية تبادل المفاتيح والتوقيع الرقمي من أجل ترحيل PQC الكامل.

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

ستناقش هذه المقالة الجدول الزمني للأحداث ذات الصلة بـ PQC، وستوفر عددًا من الإحصاءات ذات الصلة بـ PQC التي نراها عبر عملائنا. يعتمد هذا على منشورنا السابق التحضير لتشفير ما بعد الكم.

فيما يلي بعض النقاط البارزة في الأحداث ذات الصلة بـ PQC:

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

تبادل المفاتيح

كان التركيز الأصلي لجهود PQC على تبادل المفاتيح لاستخدام ML-KEM من أجل التخفيف من تهديد Harvest-Now-Decrypt-Later (HNDL). يعد تبادل مفاتيح تفاوض الجلسة لكل من TLS وSSH “مشكلة تم حلها” حيث تم تنفيذها على نطاق واسع الآن وتحتاج فقط إلى تحديث البرامج، أو، في بعض الحالات المتبقية، تنفيذ معايير تم اختبارها جيدًا. تدعم المتصفحات الحالية والعديد من خوادم إنهاء TLS TLSv1.3 مع X25519MLKEM768. وبالمثل، تدعم العديد من خوادم وعملاء SSH mlkem768x25519-sha256.

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

التوقيع الرقمي

وافق NIST على 2 من 3 خوارزميات التوقيع الرقمي (DSAs) المخطط لها. تمت الموافقة على ML-DSA (FIPS 204) وSLH-DSA (FIPS 205) منذ أواخر عام 2024. اعتبارًا من مايو 2026، ما زلنا ننتظر الموافقة على FN-DSA (FIPS 206). كل هذه لها نفس الغرض، ولكن مقايضات مختلفة. لقد أوصى NIST باستمرار باستخدام ML-DSA باعتباره “الخوارزمية الأساسية”، مما يعني أنه يجب أن يكون الخيار الأكثر استخدامًا وسيتم استخدام الخيارات الأخرى فقط في مواقف خاصة، لذا لا تنتظر الموافقة على FN-DSA.

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

على الرغم من أن FN-DSA يبدو جذابًا من البيانات الموجودة في هذا الجدول، إلا أنني أريد أن أؤكد مرة أخرى أن ML-DSA هو هدف الترحيل المفضل.

يحظى OpenSSL بدعم ML-DSA وSLH-DSA منذ الإصدار 3.5.0، الذي تم إصداره في أبريل 2025. تدعم AWS مفاتيح ML-DSA والتوقيع عبر KMS، ولكن ليس CloudHSM. يوفر GCP Cloud KMS الدعم لكل من ML-DSA-65 وSLH-DSA-SHA2-128S.

لا تزال هناك حاجة إلى دعم إضافي في المراحل الأولية لهذه بالرغم من ذلك. على سبيل المثال، لا يدعم OpenSSH حاليًا PQC للمصادقة. دعم VPN لـ PQC DSA ليس شائعًا، ولا يوجد أي دعم تقريبًا في النظام البيئي للمتصفح (المتصفحات، وحلول إنهاء TLS، وسلطات الشهادات). تتمثل المشكلة الأساسية للنظام البيئي للمتصفح في أن سلسلة الثقة من المرجع المصدق وصولاً إلى شهادة الخادم الفردي ستكون كبيرة جدًا في نموذج مقاوم للكم. يمكنك أن ترى من الجدول الاختلافات الكبيرة في حجم التوقيعات الخاصة بـ ML-DSA-44 مقابل الخوارزميات غير PQC. وللتخفيف من ذلك، سيتم ترحيل المتصفحات من سلاسل شهادات X.509 الكلاسيكية (حيث يتم تضمين كل مفتاح عام وتوقيع في السلسلة) إلى شهادات Merkle Tree (MTCs). تسمح MTCs بإثبات مدمج للتضمين، بدلاً من طلب تنزيل السلسلة الكاملة.

يختلف دعم عمليات تبادل مفاتيح PQC اختلافًا كبيرًا عبر موفري الخدمات السحابية. تستخدم خوادم API الخاصة بموفري الخدمات السحابية المختلفين HTTPS، ومن الأفضل أن تدعم جميعها تبادل المفاتيح الهجين ML-KEM. ومع ذلك، لم نتمكن من العثور على أي خوادم Azure API التي تدعم ذلك، في حين أن جميع خوادم GCP API تدعم ذلك. تدعمها AWS على 13% فقط من خوادم API الخاصة بها، استنادًا إلى خدمات محددة مثل KMS التي تدعمها.

على سبيل المثال، يذهب طلب AWS لإنشاء مفتاح وصول مستخدم IAM (وهو أمر غير مستحسن) إلى https://iam.amazonaws.com. يمكنك أن ترى في أداتنا https://www.wiz.io/pqc-tester أن خادم واجهة برمجة التطبيقات (API) لهذه الخدمة لا يدعم عمليات تبادل مفاتيح PQC، مما يعني أنه في ظل تهديد HNDL المفترض، من المحتمل أن يكون مفتاح الوصول هذا معرضًا للخطر يومًا ما. وبالمثل في Azure، يتم استخدام خادم API manager.azure.com بشكل شائع ولا يدعم عمليات تبادل مفاتيح PQC.

ولكن لمجرد دعم تبادل مفاتيح PQC، هل يتم استخدامه بالفعل من قبل المستخدمين؟ في AWS، توفر سجلات CloudTrail بعض المعلومات حول طلبات اتصال TLS المقدمة إلى واجهات برمجة تطبيقات AWS في البيئة. لا يقوم GCP وAzure بتسجيل هذا. نرى أن 84% من جميع طلبات واجهة برمجة التطبيقات (API) المقدمة إلى AWS تستخدم TLS 1.3، وهو شرط أساسي لتبادل مفاتيح PQC. تدعم AWS فقط TLS 1.2 أو 1.3 لواجهات برمجة التطبيقات الخاصة بها.

تتمتع بعض الخدمات بنسبة استخدام أعلى لـ TLS 1.3. على سبيل المثال، نرى أن 97% من طلبات خدمات التشفير KMS وACM تستخدم TLS 1.3. ومع ذلك، فإن أحداث السجل لبعض الخدمات (مثل SSM) لها استخدام قليل جدًا لـ TLS 1.3.

على الرغم من أن Secrets Manager وKMS يدعمان عمليات تبادل مفاتيح PQC، إلا أن رؤيتنا لبيانات CloudTrail توضح أن العملاء يقدمون طلبات باستخدام عمليات تبادل مفاتيح PQC لهذه الخدمات في 10% فقط من الطلبات. يعتمد التشفير الذي يستخدمه التطبيق عند الوصول إلى AWS على مكتبة التشفير الافتراضية للتطبيق. تستخدم AWS SDK for Python، والمعروفة باسم botocore، OpenSSL، وتستخدم AWS SDK for Golang مكتبة Go القياسية crypto/tls. حصل كل من OpenSSL وcrypto/tls على دعم لـ X25519MLKEM768 بحلول منتصف عام 2025. ويجب أن يكون الحصول على التطبيقات لاستخدام تبادل المفاتيح الحديث هذا مجرد مسألة تحديث مكتبات SDK وTLS الأساسية.

عندما يتعلق الأمر بالخدمات التي يقدمها موفرو الخدمات السحابية، قمنا بتحليل 42 خدمة سحابية عبر موفري الخدمات السحابية ذات الصلة بتقييمات PQC. يتضمن ذلك مفاتيح التشفير والشهادات وخدمات الشبكات (موازنات التحميل وشبكات CDN وبوابات API). لقد وجدنا أن 81% من هذه الخدمات السحابية ذات تكوينات التشفير لا تقدم حاليًا خيار تكوين متوافق مع PQC.

الإصدار 10.0 من OpenSSH، والذي تم إصداره في أبريل 2025، هو الإصدار الأول من OpenSSH الذي تم تعيينه افتراضيًا على تبادل مفاتيح PQC mlkem768x25519-sha256. يستخدم OpenSSH 9.0 (الذي تم إصداره في أبريل 2022)، تبادل مفاتيح PQC يسمى sntrup761x25519-sha512، لكن ذلك لم يكن يستفيد من معايير NIST. 4.4% من مثيلات OpenSSH تستخدم إصدارًا أكبر من أو يساوي 10.0.

أقل من 15% من مثيلات OpenSSL التي نراها في جميع بيئات الشركة تستخدم OpenSSL الذي يدعم PQC. يجب عليك استخدام OpenSSL الإصدار 3.5.0 أو أحدث، والذي تم إصداره في أبريل 2025، حتى تتمكن من استخدام PQC معه. يساعد هذا في توضيح بيانات CloudTrail السابقة حول سبب استمرار انخفاض استخدام الاتصالات بـ Secrets Manager وKMS لتبادل مفاتيح PQC.

حتى لو تمت ترقية جميع إصدارات OpenSSL، فقد تم تكوين بعضها بطريقة لا تستخدم PQC. ما يقرب من 4% من الشركات لديها مثيل واحد على الأقل من OpenSSL تم تكوينه بطريقة لا تسمح بتبادل مفاتيح PQC. إحدى الطرق التي يمكن من خلالها تكوين هذا بشكل خاطئ هي إذا قاموا بتحديد مجموعات تبادل مفاتيح محددة لاستخدامها ولم تتضمن عمليات تبادل المفاتيح التي تستخدم ML-KEM.

تدعم لغة Go X25519MLKEM768 افتراضيًا في التشفير/tls منذ 1.24، ونرى أن 60% من عمليات تثبيت Go تستخدم هذا الإصدار على الأقل.

نرى أن أقل من 1% من الشركات تستخدم مفاتيح AWS KMS لتوقيع ML-DSA.

من خلال مستشعر وقت التشغيل الخاص بنا، لدينا رؤية لاتصالات TLS الواردة إلى المضيفين الذين يقومون بإنهاء TLS الخاص بهم، كما هو الحال في مثيلات EC2 أو عقد kubernetes التي تعمل على nginx. من هذا يمكننا أن نرى أنه في حين أن 78% من TLS الوارد إليهم يستخدم TLS 1.3، فإن 22% يستخدمون TLS 1.2، ولوحظ وجود كمية صغيرة ولكن غير صفرية من TLS 1.1 و1.0. من بين TLS 1.3، 15% فقط من الاتصالات تستخدم تبادل المفاتيح المتوافق مع PQC.

في كل مكان ننظر إليه، لا يزال هناك الكثير من العمل الذي يتعين القيام به من أجل عمليات هجرة التشفير ما بعد الكم. تحتاج عمليات التنفيذ والنشر لخوارزميات التوقيع الرقمي PQC، حيث تحول التركيز مؤخرًا، إلى أقصى قدر من التحسين. يمكن لـ Wiz المساعدة في تحديد وجرد وتحديد الأولويات حيث يلزم إجراء هذه التحسينات وعمليات الترحيل. لمزيد من المعلومات حول قدرات منتجاتنا، راجع منشورنا الأخير من نقاط التشفير العمياء إلى سرعة ما بعد الكم: تقديم Wiz لجاهزية PQC.