الإصدار 3.2 من مخطّط توقيع حِزم APK

يقدّم نظام التشغيل Android 17 (المستوى 37 لواجهة برمجة التطبيقات) الإصدار 3.2 من مخطّط توقيع حِزم APK، وهو مخطّط توقيع مختلط مصمَّم لمساعدة نظام Android المتكامل على الانتقال إلى التشفير ما بعد الكم (PQC).

مع انتشار استخدام خوارزميات PQC على نطاق واسع في المجال، يوفّر المخطط الإصدار 3.2 دفاعًا متعدد الطبقات. ويجب توقيع حِزم APK باستخدام خوارزمية كلاسيكية، مثل RSA أو ECDSA، وخوارزمية PQC. يستخدم هذا الأسلوب المختلط التشفير الكلاسيكي لحماية حِزمة APK مع توفير الحماية من التهديدات التي قد تنشأ عن أجهزة الكمبيوتر الكمّية.

الغرض والتفاصيل

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

للحفاظ على الأمان ومنع الهجمات التي تتسبب في الرجوع إلى إصدار سابق أثناء عملية الانتقال هذه، يفرض المخطط v3.2 السلوكيات التالية:

• مادة المفتاح الجديد: يتطلّب الانتقال إلى حظر مختلط إنشاء مفاتيح كلاسيكية ومفاتيح مقاومة للهجمات الكمية جديدة. لا تعِد استخدام مواد المفاتيح بين الإعدادات المختلطة وغير المختلطة.
• التغيير الضمني للمفتاح: تعتبر المنصة الحظر المختلط بمثابة تغيير ضمني للمفتاح. يضيف النظام الأساسي المفتاح الكلاسيكي الجديد إلى سلسلة مفاتيح التوقيع الحالية للتطبيق باعتباره المفتاح قبل الأخير، ويتعامل مع مفتاح PQC الجديد باعتباره هوية التوقيع الحالية للتطبيق.
• السلسلة المشتركة: لتنفيذ عملية التدوير الضمني بنجاح، يجب أن يشترك كل من مفتاح التوقيع الكلاسيكي الجديد ومفتاح التوقيع المقاوم لكمبيوتر الكم الجديد ضمن الحزمة المختلطة في سلسلة التوقيع نفسها. يجب تكرار سجل التوقيع الحالي للتطبيق، سواء كان مفتاحًا أصليًا واحدًا أو سلسلة من المفاتيح التي تم تغييرها سابقًا، لكل من أدوات التوقيع الهجينة الجديدة. تستخدم المنصة هذا السجلّ المشترك للتحقّق من أنّ الجهة التي تنقل التطبيق إلى المخطط المختلط هي المالك الشرعي لهوية توقيع التطبيق الحالية.
• قيود التوقيع الفردي المقاوم لهجمات كمبيوتر الكم: أثناء الطرح الأوّلي للتوقيع المقاوم لهجمات كمبيوتر الكم، يفرض نظام التشغيل Android قيودًا صريحة على استخدام خوارزميات التوقيع المقاوم لهجمات كمبيوتر الكم في حزمة التوقيع المختلط v3.2. لا تتحقّق المنصة من إعدادات PQC الموقَّعة من جهة واحدة باستخدام أنظمة التوقيع السابقة، مثل الإصدار 2 أو 3.0 أو 3.1.
• العودة إلى الإصدار السابق: عند الانتقال من حزمة مختلطة الإصدار 3.2 إلى حزمة ذات موقّع واحد، سواء كان موقّعًا كلاسيكيًا أو موقّعًا بتقنية التشفير بعد الكمّي (PQC) عند توفّره في إصدار مستقبلي، تتحقّق المنصة من توفّر كل من المفتاح الكلاسيكي ومفتاح تقنية التشفير بعد الكمّي من الحزمة المختلطة في سلسلة التوقيع الجديدة، وتثبت صحة الموقّع الجديد.

أفضل الممارسات المتعلقة بالانتقال

للحفاظ على التوافق مع إصدارات Android الأقدم وتوفير مسار ترقية آمن أثناء الانتقال إلى توقيع PQC، يجب أن تواصل حِزم APK تضمين حزمة توقيع عادية بالإصدار 3.0 أو 3.1 موقَّعة بمفتاح تقليدي واحد. بما أنّ الإصدار 17 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 37) والإصدارات الأحدث فقط تتوافق مع المخطط المختلط 3.2، يتيح هذا الشرط للأجهزة التي تعمل بإصدارات أقدم التحقّق من التطبيق وتثبيته.

إعدادات الإجراء الاحتياطي الكلاسيكية

لتوفير شبكة أمان تشغيلية أثناء عملية الانتقال إلى PQC، عليك تنفيذ إعدادات احتياطية كلاسيكية.

• التطبيقات الحالية: يشكّل مفتاح التوقيع الحالي الثابت للتطبيق، K0، الأساس الطبيعي لهذا الخيار الاحتياطي.
• التطبيقات الجديدة: أنشئ مفتاح توقيع أساسيًا تقليديًا، K0، إلى جانب المفتاحَين المختلطَين الجديدَين، C_K1 وPQC_K1، لتحديد الهوية الأولية.

في كلتا الحالتين، يجب أن تتضمّن حزمة APK كتلة توقيع عادية بالإصدار 3.0 أو 3.1 موقَّعة بالمفتاح التقليدي K0، بالإضافة إلى كتلة مختلطة بالإصدار 3.2 موقَّعة بالمفتاحَين المختلطَين الجديدَين C_K1 وPQC_K1.

أثناء عملية النشر الأولية لمخطط الإصدار 3.2، يجب أن يمنح تسلسل التوقيع للحظر المختلط إذن الوصول إلى إمكانية ROLLBACK لـ K0. في حال حدوث مشاكل في النشر، تتيح هذه الإمكانية للتطبيق الرجوع إلى توقيع تقليدي بدون التأثير في تحديثات المستخدم. بعد أن تؤكّد بيانات وقت التشغيل الكافية أنّ عملية النشر المختلطة مستقرة، ننصحك بإزالة إمكانية ROLLBACK في التحديثات اللاحقة لتأمين مفاتيحك الجديدة بالكامل.

متطلبات الإعداد على المدى الطويل

يجب الحفاظ على إعدادات التوقيع المختلطة هذه طالما أنّ تطبيقك يستهدف إصدارًا من النظام الأساسي يتيح استخدام نظام التوقيع المختلط فقط. حتى إذا كان إصدار النظام الأساسي يتيح استخدام مفاتيح PQC ذات الموقّع الفردي، عليك توقيع أي حزمة APK تستهدف إصدارًا يتطلّب استخدام حزمة التوقيع المختلط الإصدار 3.2 باستخدام كلا المفتاحين.

كتلة الإصدار 3.2 من مخطّط توقيع حِزم APK

يخزِّن "حظر توقيع حزمة APK" حظر التوقيع بالإصدار 3.2 إلى جانب أي حظر توقيع بالإصدار 2 و3.0 و3.1.

تشبه بنية الحزمة 3.2 الإصدار 3.0، ولكنها تستخدم معرّف حزمة جديدًا، 0x70e1c89f، للإشارة إلى أنّها حزمة مختلطة. يجب أن يحتوي أي حظر صالح بتنسيق الإصدار 3.2 على جهتَين موقّعتَين بالضبط.

الخوارزميات المتوافقة

يتوافق المخطّط الإصدار 3.2 في البداية مع خوارزميات توقيع PQC التالية:

• ML-DSA-65
• ML-DSA-87

يتم إقران هذه الخوارزميات بخوارزميات التوقيع الكلاسيكية العادية، مثل تلك المتوافقة مع الإصدارين 3.0 و3.1، لتشكيل الكتلة المختلطة.

التنسيق

يخزِّن قسم توقيع حِزمة APK قسم الإصدار 3.2 من مخطّط توقيع حِزم APK ضمن المعرّف 0x70e1c89f.

يكون تنسيق الحظر v3.2 مطابقًا للتنسيق v3.0، ولكن يجب أن يحتوي التسلسل ذو المستوى الأعلى لعناصر الموقّع على إدخالَين يستهدفان إصدار حزمة SDK نفسه:

• تسلسل بادئة الطول لبرنامج التوقيع الذي يتضمّن بادئة الطول:
  
  • الموقّع الذي يتضمّن بادئة الطول (كلاسيكي)
  • الموقِّع ذو البادئة المحددة للطول (PQC)

يستخدم كل موقّع التنسيق العادي للإصدار 3:

• البيانات الموقّعة التي تتضمّن بادئة الطول:
  
  • تسلسل ملخّصات مسبوقة بالطول ومسبوقة بالطول:
  • معرّف خوارزمية التوقيع (4 بايت)
  • ملخّص (مع تحديد طوله)
  • تسلسل الشهادات الذي يسبقه الطول:
  • شهادة X.509 ذات البادئة المحددة للطول (نموذج ASN.1 DER)
  • minSDK (uint32)
  • maxSDK (عدد صحيح غير سالب 32 بت)
  • تسلسل السمات الإضافية التي تتضمّن بادئة الطول:
  • المعرّف (uint32)
  • القيمة (متغيرة الطول: طول السمة الإضافية - 4 بايت)
• minSDK (uint32)
• maxSDK (عدد صحيح غير سالب 32 بت)
• تسلسل بادئات الطول للتواقيع التي تتضمّن بادئات الطول:
  
  • معرّف خوارزمية التوقيع (4 بايت)
  • توقيع مسبوق بالطول على البيانات الموقَّعة
• مفتاح عام يتضمّن البادئة التي تحدّد الطول (SubjectPublicKeyInfo، نموذج ASN.1 DER)

إثبات الهوية

في الإصدار 17 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 37) والإصدارات الأحدث، للتحقّق من توقيع الإصدار 3.2، تتحقّق المنصة من كل من الموقّع الكلاسيكي وموقّع PQC، وتؤكّد توافقهما، وتتحقّق من سلسلة التبديل الضمني. في الإصدارات 16 من نظام Android (المستوى 36 لواجهة برمجة التطبيقات) والإصدارات الأقدم، لا يعالج النظام الأساسي حزمة التوقيع المختلطة هذه ويستخدم المخططات السابقة بدلاً منها.

تتم العملية بشكل عام على النحو التالي:

1. ابحث عن "كتلة الإصدار 3.2 من مخطّط توقيع حزمة APK" (المعرّف 0x70e1c89f).
2. تأكَّد من أنّ الحظر يتضمّن موقّعَين فقط. إذا كان عددها أقل من اثنين أو أكثر، لن تنجح عملية إثبات الملكية.
3. تأكَّد من أنّ أحد الموقّعين يستخدم خوارزمية توقيع كلاسيكية والآخر يستخدم خوارزمية توقيع مقاومة لهجمات كمبيوتر الكم. إذا كان كلاهما كلاسيكيًا أو كلاهما PQC، لن تنجح عملية التحقّق.
4. تأكَّد من أنّ كلا الموقّعَين يستهدفان نطاق حزمة SDK نفسه تمامًا (minSdkVersion وmaxSdkVersion).
5. بالنسبة إلى كل من الموقّعَين، عليك إجراء عملية التحقّق العادية من الإصدار 3:
   
   1. اختَر أقوى معرّف لخوارزمية التوقيع متوافق من التواقيع.
   2. التحقّق من التوقيع المطابق من التوقيعات مقابل البيانات الموقَّعة باستخدام المفتاح العام
   3. تأكَّد من أنّ minSdkVersionوmaxSdkVersion في البيانات الموقَّعة تتطابق مع minSdkVersionوmaxSdkVersion غير الموقَّعة.
   4. حلِّل الشهادات وتأكَّد من أنّ الشهادة الأولى تتطابق مع المفتاح العام.
   5. تحليل السمات الإضافية لاستخراج بنى صلاحية التغيير
6. التحقّق من سجلّ التوقيع (صلاحية التغيير):
   
   1. تأكَّد من أنّ كلا الموقّعَين لديهما سجلّات توقيع سابقة متطابقة.
   2. يجب أن تتطابق أطوال سلسلة الشهادات، ويجب أن تكون جميع الشهادات وعلامات الإمكانات التي تؤدي إلى الموقِّعين الحاليين متطابقة.
   3. إذا تطابقت السجلّات، ادمِج سلاسل الشهادات: عامِل شهادة الموقّع الكلاسيكي على أنّها الشهادة السابقة لشهادة الموقّع PQC، مع تعيين الموقّع PQC كعقدة طرفية حالية.
7. التحقّق من ملخّصات المحتوى:
   
   1. كرِّر خريطة الملخّصات لكل من الموقّعَين.
   2. تأكَّد من أنّ قيم الملخّص المحسوبة متطابقة بين أدوات التوقيع الكلاسيكية وأدوات التوقيع المتوافقة مع التشفير ما بعد الكم، وذلك لأي خوارزميات ملخّص متطابقة.
8. استخدِم الملخّصات المطابِقة من الموقّعين الذين تم التحقّق منهم للتحقّق من سلامة محتويات حِزمة APK (على غرار الإصدارَين 2 و3).
1. إذا كان التطبيق مثبّتًا من قبل، تحقَّق من تسلسل تحديث الحزمة:
2. التحديث من موقِّع واحد: إذا تم توقيع التطبيق المثبَّت باستخدام مفتاح كلاسيكي واحد، يجب أن يكون هذا المفتاح متوفّرًا في سلسلة التوقيع الخاصة بكتلة التوقيع المختلط الجديدة باعتباره مفتاحًا سابقًا لمفاتيح التوقيع المختلطة.
3. التحديث من أداة توقيع مختلطة لمواصلة استخدام التوقيع المختلط: إذا تم توقيع التطبيق المثبَّت باستخدام حزمة مختلطة بالإصدار 3.2، يجب أن يظل المفتاحان الكلاسيكي والمقاوم لهجمات كمبيوتر الكم السابقان أداتَي التوقيع النشطتَين الحاليّتَين في حزمة APK المعدَّلة بالإصدار 3.2، أو يجب أن يكونا كلاهما متوفّرَين في سلسلة التوقيع الجديدة التي تشهد على المفاتيح المختلطة الجديدة التي تم تدويرها.
4. الانتقال من التوقيع المختلط: إذا تم توقيع التطبيق المثبَّت باستخدام كتلة مختلطة من الإصدار 3.2، وتمت إعادة توجيه حزمة APK للتحديث إلى موقِّع واحد (إما مقاوم لهجمات كمبيوتر الكم أو كلاسيكي)، يجب أن يكون كلا الموقِّعَين المختلطَين السابقَين متوفّرَين في سلسلة توقيع حزمة APK للتحديث وأن يثبتا مفتاح التوقيع الفردي الجديد.
5. مسارات التحديث غير صالحة: إذا حاول أحد المطوّرين تحديث تطبيق موقَّع بشكل مختلط باستخدام أحد المفتاحَين المختلطَين فقط كموقِّع واحد بدون تدوير المفتاح بشكل صحيح، سيفشل التحديث. يجب أن يكون كلا المفتاحين مشاركًا بشكل صريح في أي عملية انتقال لمنع هجمات الرجوع إلى إصدار أقدم.
9. إذا تعذّرت أي خطوة، ستتعذّر عملية إثبات الملكية.

الحماية من إزالة البيانات

لمنع الهجمات التي تتسبب في الرجوع إلى إصدار سابق من أنظمة التوقيع، يتضمّن نظام الإصدار 3.2 سمات حماية من التجريد مشابهة لتكرارات النظام السابقة.

تكتب أداة التوقيع سمتَين محدّدتين لحماية عملية إزالة التداخل المختلط في السمات الإضافية لكتل التوقيع بالإصدارَين 3.0 و3.1. تحدّد هذه السمات الحدود الدقيقة لإصدار حزمة SDK التي يجب أن تتوفّر فيها الوحدة المختلطة بالإصدار 3.2 وأن يتم التحقّق منها:

• سمة الحد الأدنى لإصدار حزمة تطوير البرامج (المعرّف 0xbf940529): تحدّد قيمة هذه السمة الحد الأدنى لإصدار حزمة تطوير البرامج المتوافق مع وحدة التوقيع المختلط.
• سمة الحد الأقصى لإصدار حزمة SDK (المعرّف 0x9f06b79c): تحدّد قيمة هذه السمة الحد الأقصى لإصدار حزمة SDK الذي يتوافق معه قسم التوقيع المختلط. تتيح لك هذه السمة الانتقال إلى إعدادات التوقيع الفردي عندما لا تتطلّب إصدارات النظام الأساسي الأحدث التوقيع المختلط.

إذا تخطّت المنصة عملية التحقّق من الإصدار 3.2 لأنّ الحظر غير متوفّر أو أنّ نطاق حزمة SDK لا ينطبق على الجهاز، تتحقّق المنصة من حِزمة APK مقارنةً بالحظر التالي المتوفّر. إذا كانت تلك الفقرة السابقة تحتوي على سمات الحماية من الإزالة، ستجري المنصة عمليات التحقّق التالية:

• التحقّق من التواجد والنطاق: إذا كانت كتلة التوقيع بالإصدار 3.0 أو 3.1 تحتوي على سمة الحد الأدنى لإصدار حزمة تطوير البرامج (المعرّف 0xbf940529، القيمة X) أو سمة الحد الأقصى لإصدار حزمة تطوير البرامج (المعرّف 0x9f06b79c، القيمة Y)، يتطلّب النظام الأساسي توفُّر كتلة مختلطة بالإصدار 3.2 ضمن حزمة APK. يقرأ النظام الأساسي الحزمة المختلطة للتحقّق من أنّ نطاق حزمة SDK المستهدَفة يتطابق مع الحدود المحدّدة بواسطة هذه السمات. إذا كان جزء v3.2 غير متوفّر، أو إذا كانت قيمتا الحد الأدنى والحد الأقصى الداخليتَين المستهدفتَين لإصدار حزمة تطوير البرامج (SDK) لا تساويان X وY، سترفض المنصة عملية التثبيت.
• التنفيذ ضمن النطاق: إذا كان إصدار حزمة تطوير البرامج (SDK) على الجهاز يقع ضمن النطاق الصالح الذي تحدّده هذه السمات، أي أكبر من X أو يساويها، وأقل من Y أو يساويها عند تقديم السمة القصوى، يتطلّب النظام الأساسي بشكل صارم استخدام الحزمة المختلطة 3.2 للتحقّق من التوقيع. إذا تحقّقت المنصة من حظر الإصدار 3.0 أو 3.1 على جهاز ضمن نطاق حزمة تطوير البرامج (SDK) المستهدَفة هذا، سترفض المنصة عملية التثبيت لأنّه تم تجاوز حظر الإصدار 3.2 أو إزالته بشكل ضار.

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

التحقّق من صحة عملية التنفيذ

لاختبار عملية تنفيذ نظام التوقيع الإصدار 3.2، شغِّل HybridSignatureVerificationTest.java اختبارات CTS المتوفّرة في cts/hostsidetests/appsecurity/src/android/appsecurity/cts/.

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