ملخص
يدعم Android 13 الإصدار 3.1 من APK Signature Scheme، وهو تحسين على الإصدار 3 من APK Signature Scheme الحالي. يعالج نظام v3.1 بعض المشكلات المعروفة في APK Signature Scheme v3 فيما يتعلق بالتدوير. على وجه الخصوص، يدعم نظام التوقيع v3.1 استهداف إصدار SDK، والذي يسمح بالتناوب لاستهداف إصدار أحدث من النظام الأساسي.
يستخدم نظام التوقيع v3.1 معرف كتلة لم يتم التعرف عليه على نظام التشغيل Android 12 أو الإصدارات الأقدم. ولذلك، يطبق النظام الأساسي سلوك المُوقع التالي:
- تستخدم الأجهزة التي تعمل بنظام التشغيل Android 13 أو الإصدارات الأحدث أداة التوقيع المُدارة في الإصدار 3.1.
- تتجاهل الأجهزة التي تعمل بإصدارات أقدم من Android المُوقع المُدار وتستخدم بدلاً من ذلك المُوقع الأصلي في كتلة الإصدار 3.
لا تتطلب التطبيقات التي لم تقم بتدوير مفتاح التوقيع الخاص بها بعد أي إجراء إضافي. عندما تختار هذه التطبيقات التدوير، يقوم النظام بتطبيق نظام التوقيع v3.1 افتراضيًا.
كتلة التوقيع v3.1
ستحتوي كتلة التوقيع v3.1 على نفس محتويات كتلة التوقيع v3، ولكن باستخدام معرف الكتلة الجديد، لن يتم التعرف على هذه التوقيعات إلا على الأجهزة التي تعمل بنظام التشغيل Android 13 والإصدارات الأحدث. يسمح هذا للتطبيقات بتدوير مفاتيح التوقيع الخاصة بها بأمان دون الحاجة إلى القلق بشأن ملفات APK متعددة الأهداف حيث يمكن استخدام الموقّع الأصلي لتوقيع APK في كتلة التوقيع v3 والموقّع الذي تم تدويره في كتلة التوقيع v3.1. يسمح هذا أيضًا للنظام الأساسي بإعادة استخدام جميع رموز التحقق الحالية لكتلة التوقيع v3 عند التحقق من توقيع v3.1.
افتراضيًا، ستستخدم مكتبة apksig كتلة التوقيع v3.1 عندما يتم توفير مفتاح تم تدويره وسلالة في تكوين التوقيع. إذا كان minSdkVersion لأحد التطبيقات أقل من Android 13 وكان يتم استخدام مفتاح مستدير، فيجب تحديد مفتاح التوقيع الأصلي أيضًا حتى يمكن استخدامه لتوقيع APK في كتلة التوقيع v3. يشبه هذا السلوك الحالي حيث يُطلب من الموقّع الأصلي إذا كان APK يستهدف إصدارًا أقدم من Android 9.
لدعم استهداف تدوير المفاتيح بدءًا من إصدار SDK معين، ستعرض مكتبة apksig واجهات برمجة التطبيقات الجديدة التي ستسمح بتعيين الحد الأدنى لإصدار SDK للتدوير. إذا تم تحديد إصدار SDK أقل من Android 13 باعتباره الحد الأدنى للإصدار لدعم التدوير، فسيتم تحديد الإصدار v3 الأصلي سيتم استخدام الكتلة. يتم استخدام كتلة التوقيع v3.1 فقط في حالة التدوير حيث يتم تعيين الحد الأدنى لإصدار SDK للتدوير على Android 13 والإصدارات الأحدث. ستحتوي كتلة التوقيع v3 على سمة جديدة للحد الأدنى من حماية تجريد إصدار SDK.
| APK يتضمن النسب | قيمة إصدار التدوير الأدنى لـ sdk | كتلة التوقيع v3 | كتلة التوقيع v3.1 |
|---|---|---|---|
| لا | القيمة الافتراضية أو أي قيمة (يمثلها x أدناه) | مُوقع باستخدام المُوقع الأصلي، ويستهدف Android 9 والإصدارات الأحدث | غير موجود |
| نعم | تقصير | مُوقع باستخدام المُوقع الأصلي، ويستهدف Android 9 حتى 12L | تم التوقيع باستخدام مُوقع مستدير، يستهدف Android 13 والإصدارات الأحدث |
| نعم | س <33 (أندرويد 13) | تم التوقيع باستخدام مُوقع مستدير، يستهدف Android 9 والإصدارات الأحدث | غير موجود |
| نعم | س >= 33 (أندرويد 13) | تم التوقيع باستخدام المُوقع الأصلي، لاستهداف Android 9 - ( x -1) | تم التوقيع باستخدام مُوقِّع مستدير، يستهدف x+ |
القضايا المتعلقة بالتناوب
تم حل المشكلات التالية المتعلقة بالتناوب في النظام الأساسي:
إصلاحات أندرويد 12
- لن يمنح النظام الأساسي إذن التوقيع للتطبيق الطالب إلا إذا كان الموقّع الحالي لأي من التطبيقين في سلسلة التوقيع، أو هو الموقّع الحالي للتطبيق الآخر؛ يمنع هذا منح إذن التوقيع للتطبيق الطالب إذا كان التطبيقان يتبعان أفضل ممارسات التوقيع الرئيسية ويتناوبان على مفاتيح توقيع مختلفة.
- لا يمكن لميزة التراجع عن APK الخاصة بالمنصة استرجاع APK الذي تم تدوير مفتاح التوقيع الخاص به ما لم يكن المفتاح السابق في سلسلة التوقيع يتمتع بإمكانية التراجع، ولكن هذه الإمكانية تتعارض مع غرض التدوير لأنها تسمح بتوقيع تحديث الحزمة الجديدة بواسطة مفتاح التوقيع السابق واستعادة المفتاح الذي تم تدويره.
- ملف APK الذي تم توقيعه باستخدام المفتاح المُدار فقط وتم تحديثه لاحقًا باستخدام ملف APK مُوقع بالمفتاح الأصلي والمفتاح المُدار في السلسلة سيُظهر فقط المفتاح المُدار في السلسلة على الأجهزة التي تعمل بنظام Android 11 والإصدارات الأقدم.
إصلاحات أندرويد 11
- لم يتم تحديث
PackageManager#checkSignaturesبشكل صحيح للتحقق من مفاتيح التوقيع الأصلية لحزمتين. أدى هذا إلى تعطيل الأجهزة للتطبيقات التي تستخدم مفتاح توقيع مستدير مع APK للأجهزة باستخدام مفتاح التوقيع الأصلي. - تشترك الحزم الموجودة ضمن
sharedUserIdفي نسب التوقيع الخاصة بها. عندما يتم تثبيت تطبيق بتسلسل توقيع محدث أو تحديثه فيsharedUiserId، فإن سلسلة هذا التطبيق تحل محل السلسلة المشتركة لـsharedUserId(أي، إذا كانت سلسلة توقيع التطبيق هي A -> B، ويتم تحديث التطبيق فيsharedUserIdمع السلالة B -> C، سيتم استبدال سلالةsharedUserIdبـ B -> C). وبالمثل، لا يمكن تحديث قدرات الموقع السابق في النسب ما لم يتم تغيير نسب التوقيع.
التكامل v4
يستخدم نظام التوقيع v4 تكوين التوقيع المقدم إلى apksigner؛ في حالة تكوينات التوقيع المتعددة المتوفرة للتناوب، يتم استخدام أحدث تكوين للتوقيع الذي تم تدويره. قبل تقديم الإصدار 3.1، كان الإصدار 3 يتضمن فقط هذا التكوين الأخير للتوقيع الدائري، لذلك كان الإصدار 4 قادرًا على استخدام هذا التكوين كما هو؛ وبهذا أصبح نظام التوقيع v4 قادرًا على دعم التدوير لأنه استخدم مفتاح التوقيع المُدار في SigningInfo الخاص به. على الرغم من أن v4 SigningInfo لا يتضمن نسب التوقيع الكامل، إلا أنه قادر على سحب ذلك من كتلة التوقيع v3 للسماح للمنصة بالوصول إلى النسب لأي استعلامات توقيع. عندما يكون الإصدار 3.1 قيد الاستخدام لاستهداف التدوير لإصدار Rotation-min-sdk المقدم، سيتضمن تكوين v3 العام كلاً من تكوين التوقيع الأصلي بالإضافة إلى أحدث تكوين توقيع تم تدويره. تم إنشاء امتداد لنظام التوقيع v4 الذي يتضمن كتل معلومات التوقيع الإضافية لكل تكوينات التوقيع من الكتلة v3.1.
تصديق
لاختبار تنفيذ الإصدار 3.1، قم بتشغيل اختبارات PkgInstallSignatureVerificationTest.java CTS في cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .
لمزيد من المعلومات حول الاختبار، راجع قسم التحقق في الإصدار 3.