اندروید ۱۷ (سطح API ۳۷) طرح امضای APK نسخه ۳.۲ را معرفی میکند، یک طرح امضای ترکیبی که برای پشتیبانی از گذار اکوسیستم اندروید به رمزنگاری پساکوانتومی (PQC) طراحی شده است.
همزمان با گسترش الگوریتمهای PQC در مقیاس وسیع توسط صنعت، طرح نسخه ۳.۲ دفاع در عمق را فراهم میکند. این طرح شما را ملزم میکند که APKها را هم با یک الگوریتم کلاسیک مانند RSA یا ECDSA و هم با یک الگوریتم PQC امضا کنید. این رویکرد ترکیبی از رمزنگاری کلاسیک برای محافظت از APK شما و در عین حال دفاع در برابر تهدیدات رایانههای کوانتومی استفاده میکند.
هدف و جزئیات
طرح نسخه ۳.۲ به عنوان یک مکانیسم انتقالی استاندارد و مطابق با صنعت عمل میکند. با این رویکرد ترکیبی، شما از مزایای مقاومت کوانتومی PQC بهرهمند میشوید و در عین حال به امنیت اثباتشده الگوریتمهای امضای کلاسیک تکیه میکنید. هنگامی که الگوریتمهای PQC تازه استاندارد شده به بلوغ عملیاتی در مقیاس برسند، میتوانید از این پیکربندی ترکیبی به یک کلید امضای PQC واحد منتقل شوید. پشتیبانی پلتفرم برای طرح امضای نسخه ۳.۲ با اندروید ۱۷ آغاز میشود. نسخههای پایینتر اندروید از بلوک v3.2 صرف نظر میکنند و از طرحهای قبلی برای تأیید امضا استفاده میکنند.
برای حفظ امنیت و جلوگیری از حملات downgrade در طول این انتقال، طرح v3.2 رفتارهای زیر را اعمال میکند:
- ماده کلید جدید: انتقال به یک بلوک ترکیبی نیاز به تولید کلیدهای کلاسیک و PQC جدید دارد. از ماده کلید بین پیکربندیهای ترکیبی و غیرترکیبی دوباره استفاده نکنید.
- چرخش ضمنی: پلتفرم، بلوک ترکیبی را به عنوان یک چرخش ضمنی کلید در نظر میگیرد. پلتفرم، کلید کلاسیک جدید را به عنوان کلید یکی مانده به آخر به دودمان امضای موجود برنامه اضافه میکند و کلید PQC جدید را به عنوان هویت امضای فعلی برنامه در نظر میگیرد.
- دودمان مشترک: برای اجرای موفقیتآمیز چرخش ضمنی، هم کلید کلاسیک جدید و هم کلید PQC جدید درون بلوک ترکیبی باید تبار امضای یکسانی داشته باشند. شما باید تاریخچه امضای موجود برنامه - چه یک کلید اصلی واحد یا دودمانی از کلیدهای قبلاً چرخانده شده - را برای هر دو امضاکننده ترکیبی جدید کپی کنید. پلتفرم از این دودمان مشترک برای تأیید اینکه نهادی که برنامه را به طرح ترکیبی منتقل میکند، مالک قانونی هویت امضای فعلی برنامه است، استفاده میکند.
- محدودیت امضای تکی PQC: در طول عرضه اولیه PQC، اندروید صراحتاً استفاده از الگوریتمهای PQC را به بلوک ترکیبی نسخه ۳.۲ محدود میکند. این پلتفرم پیکربندی PQC تکی را با استفاده از طرحهای امضای قبلی، مانند نسخه ۲، نسخه ۳.۰ یا نسخه ۳.۱، تأیید نمیکند.
- بازگشت به عقب: هنگام بازگشت از یک بلوک ترکیبی نسخه ۳.۲ به یک بلوک تک امضاکننده - چه یک امضاکننده کلاسیک و چه یک امضاکننده PQC در صورت پشتیبانی در نسخههای آینده - پلتفرم تأیید میکند که هر دو کلید کلاسیک و PQC از بلوک ترکیبی در دودمان امضای جدید وجود دارند و امضای تک امضاکننده جدید را تأیید میکنند.
بهترین شیوهها برای گذار
برای حفظ سازگاری با نسخههای پایینتر اندروید و ارائه یک مسیر ارتقاء امن در طول گذار به امضای PQC، فایلهای APK باید همچنان شامل یک بلوک امضای استاندارد v3.0 یا v3.1 باشند که توسط یک کلید کلاسیک واحد امضا شده است. از آنجا که فقط اندروید ۱۷ (سطح API ۳۷) و بالاتر از طرح ترکیبی v3.2 پشتیبانی میکنند، این الزام به دستگاههایی که نسخههای پایینتر را اجرا میکنند اجازه میدهد تا برنامه را تأیید و نصب کنند.
پیکربندی جایگزین کلاسیک
برای فراهم کردن یک شبکه ایمنی عملیاتی در طول انتقال PQC، یک پیکربندی جایگزین کلاسیک پیادهسازی کنید.
- برنامههای موجود: کلید امضای فعلی برنامه، K0، به عنوان پایه طبیعی این جایگزین عمل میکند.
- برنامههای جدید: یک کلید امضای کلاسیک پایه، K0، در کنار کلیدهای ترکیبی جدید، C_K1 و PQC_K1، برای ایجاد هویت اولیه ایجاد کنید.
در هر دو سناریو، APK باید شامل یک بلوک امضای استاندارد v3.0 یا v3.1 باشد که توسط کلید کلاسیک، K0، امضا شده است، در کنار بلوک ترکیبی v3.2 که توسط کلیدهای ترکیبی جدید، C_K1 و PQC_K1، امضا شده است.
در طول استقرار اولیه طرح نسخه ۳.۲، دودمان امضای بلوک ترکیبی باید قابلیت ROLLBACK را به K0 اعطا کند. در صورت بروز مشکلات استقرار، این قابلیت به برنامه اجازه میدهد بدون ایجاد اختلال در بهروزرسانیهای کاربر، به امضای کلاسیک بازگردد. هنگامی که دادههای زمان اجرا کافی، پایداری استقرار ترکیبی را تأیید کردند، توصیه میکنیم قابلیت ROLLBACK را در بهروزرسانیهای بعدی حذف کنید تا کلیدهای جدید شما کاملاً ایمن شوند.
الزامات پیکربندی بلندمدت
شما باید این پیکربندی امضای ترکیبی را تا زمانی که برنامه شما برای انتشار یک پلتفرم که منحصراً از طرح ترکیبی پشتیبانی میکند، در نظر گرفته شده است، حفظ کنید. حتی اگر یک نسخه پلتفرم از کلیدهای PQC تک امضاکننده پشتیبانی کند، باید هر APK را که برای انتشاری که به بلوک ترکیبی v3.2 نیاز دارد، با هر دو کلید امضا میکند، امضا کنید.
بلوک طرح امضای APK نسخه ۳.۲
بلوک امضای APK، بلوک امضای نسخه ۳.۲ را در کنار هر بلوک امضای نسخه ۲، نسخه ۳.۰ و نسخه ۳.۱ ذخیره میکند.
ساختار بلوک نسخه ۳.۲ مشابه نسخه ۳.۰ است، اما از یک شناسه بلوک جدید، 0x70e1c89f ، برای نشان دادن اینکه یک بلوک ترکیبی است، استفاده میکند. یک بلوک معتبر نسخه ۳.۲ باید دقیقاً شامل دو امضاکننده باشد.
الگوریتمهای پشتیبانیشده
طرح نسخه ۳.۲ در ابتدا از الگوریتمهای امضای PQC زیر پشتیبانی میکند:
- ML-DSA-65
- ML-DSA-87
اینها با الگوریتمهای امضای کلاسیک استاندارد، مانند آنهایی که در نسخههای ۳.۰ و ۳.۱ پشتیبانی میشوند، جفت میشوند تا بلوک ترکیبی را تشکیل دهند.
قالب
بلوک امضای APK، بلوک طرح امضای APK نسخه ۳.۲ را با شناسه 0x70e1c89f ذخیره میکند.
قالب بلوک نسخه ۳.۲ با نسخه ۳.۰ یکسان است، اما توالی سطح بالای عناصر امضاکننده باید دقیقاً شامل دو ورودی باشد که نسخه SDK یکسانی را هدف قرار میدهند:
- دنباله با پیشوند طولی از امضاکننده با پیشوند طولی:
- امضاکننده با پیشوند طولی (کلاسیک)
- امضاکننده با پیشوند طولی (PQC)
هر امضاکننده از قالب استاندارد v3 استفاده میکند:
- دادههای امضا شده با پیشوند طول:
- دنباله پیشوندی طولی از خلاصههای پیشوندی طولی:
- شناسه الگوریتم امضا (۴ بایت)
- خلاصه (با پیشوند طول)
- توالی گواهیها با پیشوند طولی:
- گواهی X.509 با پیشوند طولی (فرم ASN.1 DER)
- حداقل SDK (از نوع uint32)
- حداکثر SDK (از نوع uint32)
- دنباله با پیشوند طول از ویژگیهای اضافی با پیشوند طول:
- شناسه (uint32)
- مقدار (variable-length: طول ویژگی اضافی - ۴ بایت)
- حداقل SDK (از نوع uint32)
- حداکثر SDK (از نوع uint32)
- دنباله پیشوندی طولی از امضاهای پیشوندی طولی:
- شناسه الگوریتم امضا (۴ بایت)
- امضای با پیشوند طول روی دادههای امضا شده
- کلید عمومی با پیشوند طول (
SubjectPublicKeyInfo، فرم ASN.1 DER)
تأیید
در اندروید ۱۷ (سطح API ۳۷) و بالاتر، برای تأیید امضای نسخه ۳.۲، پلتفرم هم امضاکنندههای کلاسیک و هم امضاکنندههای PQC را تأیید میکند، سازگاری آنها را تأیید میکند و دودمان چرخش ضمنی را بررسی میکند. در اندروید ۱۶ (سطح API ۳۶) و نسخههای پایینتر پلتفرم، پلتفرم این بلوک امضای ترکیبی را پردازش نمیکند و به جای آن از طرحهای قبلی استفاده میکند.
روند کلی به شرح زیر است:
- بلوک APK Signature Scheme v3.2 (شناسه 0x70e1c89f) را پیدا کنید.
- تأیید کنید که بلوک دقیقاً شامل دو امضاکننده است. اگر تعداد کمتر یا بیشتر از دو نفر باشد، تأیید ناموفق خواهد بود.
- تأیید کنید که یکی از امضاکنندگان از الگوریتم امضای کلاسیک و دیگری از الگوریتم امضای PQC استفاده میکند. اگر هر دو کلاسیک یا هر دو PQC باشند، تأیید ناموفق خواهد بود.
- تأیید کنید که هر دو امضاکننده دقیقاً محدوده SDK یکسانی (
minSdkVersionوmaxSdkVersion) را هدف قرار میدهند. - برای هر یک از دو امضاکننده، تأیید استاندارد نسخه ۳ را انجام دهید:
- قویترین شناسه الگوریتم امضای پشتیبانیشده را از بین امضاها انتخاب کنید.
- امضای مربوطه را از امضاها در برابر دادههای امضا شده با استفاده از کلید عمومی تأیید کنید.
- تأیید کنید که
minSdkVersionوmaxSdkVersionدر دادههای امضا شده باminSdkVersionوmaxSdkVersionبدون امضا مطابقت دارند. - گواهیها را تجزیه کنید و تأیید کنید که گواهی اول با کلید عمومی مطابقت دارد.
- ویژگیهای اضافی را برای استخراج ساختارهای اثبات چرخش تجزیه کنید.
- تأیید سابقه امضا (اثبات چرخش):
- بررسی کنید که هر دو امضاکننده، سابقه امضاهای قبلی یکسانی داشته باشند.
- طول دودمانها باید مطابقت داشته باشد، و تمام گواهینامهها و پرچمهای قابلیت منتهی به امضاکنندگان فعلی باید یکسان باشند.
- اگر تاریخچهها مطابقت داشتند، دودمانها را ادغام کنید: گواهی امضاکننده کلاسیک را به عنوان گواهی سلف گواهی امضاکننده PQC در نظر بگیرید و امضاکننده PQC را به عنوان گره پایانی فعلی اختصاص دهید.
- خلاصههای محتوا را تأیید کنید:
- نقشه خلاصهها را برای هر دو امضاکننده تکرار کنید.
- تأیید کنید که برای هر الگوریتم خلاصه تطبیقی، مقادیر خلاصه محاسبهشده بین امضاکنندگان کلاسیک و PQC یکسان هستند.
- برای تأیید صحت محتوای APK (مشابه نسخه ۲ و ۳)، از خلاصههای مطابقتیافته از امضاکنندگان تأییدشده استفاده کنید.
- اگر برنامه از قبل نصب شده است، اصل و نسب بهروزرسانی بسته را بررسی کنید:
- بهروزرسانی از یک امضاکنندهی واحد: اگر برنامهی نصبشده با یک کلید کلاسیک واحد امضا شده باشد، آن کلید باید در دودمان امضای بلوک ترکیبی جدید به عنوان سلف امضاکنندگان ترکیبی وجود داشته باشد.
- بهروزرسانی از یک امضاکننده ترکیبی برای ادامه حالت ترکیبی: اگر برنامه نصبشده با یک بلوک ترکیبی نسخه ۳.۲ امضا شده باشد، هر دو کلید کلاسیک و PQC قبلی باید یا به عنوان امضاکنندههای فعال فعلی در بلوک نسخه ۳.۲ بهروزرسانی APK باقی بمانند، یا هر دو باید در دودمان امضای جدید که گواهی بر کلیدهای ترکیبی تازه تغییر یافته است، وجود داشته باشند.
- گذار از یک امضاکننده ترکیبی: اگر برنامه نصب شده با یک بلوک ترکیبی نسخه ۳.۲ امضا شده باشد و APK بهروزرسانیشده به یک امضاکننده واحد (PQC یا کلاسیک) بازگردد، هر دو امضاکننده ترکیبی قبلی باید در دودمان امضای APK بهروزرسانیشده وجود داشته باشند و کلید امضای واحد جدید را تأیید کنند.
- مسیرهای بهروزرسانی نامعتبر: اگر یک توسعهدهنده تلاش کند تا یک برنامه با امضای ترکیبی را تنها با استفاده از یکی از کلیدهای ترکیبی به عنوان یک امضاکننده واحد و بدون چرخش مناسب بهروزرسانی کند، بهروزرسانی با شکست مواجه میشود. هر دو کلید باید صریحاً در هر انتقال دخیل باشند تا از حملات تنزل رتبه جلوگیری شود.
- اگر هر مرحلهای با شکست مواجه شود، تأیید با شکست مواجه میشود.
محافظت در برابر ساییدگی
برای جلوگیری از حملات تنزل به طرحهای امضای پایینتر، طرح نسخه ۳.۲ شامل حذف ویژگیهای محافظتی مشابه تکرارهای طرح قبلی است.
ابزار امضا، دو ویژگی خاص محافظت در برابر حذف ترکیبی را در ویژگیهای اضافی بلوکهای امضای v3.0 و v3.1 مینویسد. این ویژگیها، مرزهای دقیق نسخه SDK را که بلوک ترکیبی v3.2 باید در آنها وجود داشته باشد و تأیید شود، تعریف میکنند:
- ویژگی حداقل نسخه SDK (شناسه
0xbf940529): مقدار این ویژگی، حداقل نسخه SDK پشتیبانی شده توسط بلوک امضای ترکیبی را تعیین میکند. - ویژگی حداکثر نسخه SDK (شناسه
0x9f06b79c): مقدار این ویژگی، حداکثر نسخه SDK که بلوک امضای ترکیبی پشتیبانی میکند را تعیین میکند. این ویژگی به شما امکان میدهد وقتی نسخههای بالاتر پلتفرم به امضای ترکیبی نیاز ندارند، به پیکربندی تک امضاکننده بروید.
اگر پلتفرم به دلیل فقدان بلوک یا عدم اعمال محدوده SDK آن به دستگاه، از تأیید نسخه ۳.۲ صرف نظر کند، پلتفرم APK را با بلوک بعدی موجود تأیید میکند. اگر بلوک قبلی حاوی این ویژگیهای محافظت در برابر حذف باشد، پلتفرم بررسیهای زیر را اعمال میکند:
- تأیید حضور و محدوده: اگر یک بلوک امضای نسخه ۳.۰ یا ۳.۱ شامل حداقل ویژگی SDK (شناسه
0xbf940529، مقدار X ) یا حداکثر ویژگی SDK (شناسه0x9f06b79c، مقدار Y ) باشد، پلتفرم الزام میکند که بلوک ترکیبی نسخه ۳.۲ در داخل APK وجود داشته باشد. پلتفرم بلوک ترکیبی را میخواند تا تأیید کند که محدوده SDK هدف آن با مرزهای مشخص شده توسط این ویژگیها مطابقت دارد. اگر بلوک نسخه ۳.۲ وجود نداشته باشد، یا اگر مقادیر هدف SDK حداقل و حداکثر داخلی آن برابر با X و Y نباشد، پلتفرم نصب را رد میکند. - اجرا در محدوده: اگر نسخه SDK دستگاه در محدوده معتبر مشخص شده توسط این ویژگیها قرار گیرد - که بزرگتر یا مساوی X و کوچکتر یا مساوی Y است (در صورت ارائه حداکثر ویژگی) - پلتفرم اکیداً به بلوک ترکیبی v3.2 برای تأیید امضا نیاز دارد. اگر پلتفرم یک بلوک v3.0 یا v3.1 را در دستگاهی در این محدوده SDK هدف تأیید کند، پلتفرم نصب را رد میکند زیرا بلوک v3.2 به طور مخربی دور زده شده یا حذف شده است.
با اعمال این مرزها، پلتفرم تعیین میکند که چه زمانی یک APK باید حاوی بلوک v3.2 باشد. اگر این بلوک حذف شده باشد، پلتفرم نصب را رد میکند تا از حملهی تنزل رتبه جلوگیری کند.
اعتبارسنجی پیادهسازی شما
برای آزمایش پیادهسازی طرح امضای نسخه ۳.۲، تستهای CTS مربوط به HybridSignatureVerificationTest.java واقع در cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ را اجرا کنید.
این آزمایشها مجموعهای جامع از سناریوها، از جمله نصبهای موفقیتآمیز، بهروزرسانیها از نسخههای کلاسیک، انتقال به نسخههای قدیمیتر با استفاده از قابلیت ROLLBACK و تأیید کاهش حملات stripping را پوشش میدهند.