برای افزایش بیشتر اعتماد به سیستم عامل اندروید، ما متعهد هستیم که هر ماژول سیستم عامل اندروید (به نام Mainline ) را که به عنوان بهروزرسانی از طریق گوگل پلی ارائه میشود، در گزارش شفافیت خود فهرست کنیم. ما گزارش شفافیت را منتشر میکنیم تا ادعاهایی را که در مورد این ماژولها مطرح میکنیم، تأیید کنیم. ماژولهای از پیش نصب شده به صراحت فهرست نشدهاند، زیرا از قبل تحت پوشش شفافیت پیکسل باینری قرار دارند.
مدل تهدید
سیستمهای شفافیت میتوانند برای شناسایی و در نتیجه جلوگیری از حملات زنجیره تأمین مورد استفاده قرار گیرند. ما با چند مثال این موضوع را روشن میکنیم.
فرض کنید یک مهاجم به طور مخرب یک ماژول Mainline (که میتواند یک فایل APEX از نوع APK باشد) را تغییر دهد و حتی موفق شود آن را با کلید امضایی که برای توزیع از طریق Google Play استفاده میشود، امضا کند. هر کسی که یک ماژول مشکوک دریافت کند، میتواند گزارش شفافیت دودویی را برای تأیید صحت ماژول جستجو کند. آنها متوجه خواهند شد که گوگل فراداده ماژول مربوطه را به گزارش اضافه نکرده است و متوجه میشوند که نباید به ماژول سیستم عامل آسیبدیده اعتماد کنند.
از آنجایی که انتشار در لاگ فرآیندی جداگانه از فرآیند آزادسازی امضا است، این امر برای مهاجم، فراتر از به خطر انداختن کلید، موانع را افزایش میدهد.
در حالی که ما قصد داریم این گزارش را با استفاده از یک پروتکل استاندارد شاهد ، در یک شبکه عمومی از شاهدان ادغام کنیم، طرفهای خارجی و مستقل را تشویق میکنیم تا بر صحت این گزارش که در دسترس عموم است، نظارت کنند. این طرفها میتوانند ویژگی فقط-افزودن گزارش را تأیید کنند و هرگونه دستکاری را گزارش دهند.
وجود چنین سیستم شفافیتی و قابلیت کشف حملات، فعالیتهای مخرب را کاهش میدهد. اگر یک ماژول سیستم عامل مورد نفوذ قرار گیرد اما کاربران فقط به ماژولهای موجود در گزارش اعتماد کنند، ماژول مورد نفوذ باید به صورت عمومی در معرض دید عموم قرار گیرد. این امر احتمال کشف وجود ماژولهای مورد نفوذ را افزایش میدهد و میتوان برای حذف توزیع آن اقدام کرد.
مدل مدعی
مدل مدعی ، چارچوبی است که برای تعریف نقشها و مصنوعات در یک سیستم قابل تأیید استفاده میشود. در مورد شفافیت ماژولهای اصلی اندروید، ادعایی که ما مطرح میکنیم این است که هش یک فایل ماژول ثبت شده در این لاگ، نشاندهنده نسخه خاصی از یک ماژول رسمی اندروید است که برای مصرف عمومی در نظر گرفته شده است.
- ادعای MainlineModule : (من، گوگل، ادعا میکنم که
$hashModuleبرای$mainlineModuleاست)، که در آن:
هر کسی که یک کپی از $mainlineModule داشته باشد میتواند این ادعا را تأیید کند. صفحه تأیید، دستورالعملهای دقیقی برای این فرآیند ارائه میدهد. این مراحل هم برای APKهای معمولی و هم برای ماژولهای Mainline (که میتوانند فایلهای APK یا APEX باشند) اعمال میشود.
محتوای گزارش
وقتی گوگل نسخه جدیدی از یک ماژول Mainline را منتشر میکند، یک ورودی مربوطه را به گزارش شفافیت ماژولهای Mainline اضافه میکند.
هر ورودی در این لاگ شامل چهار قطعه فراداده است:
- هش APK یا APEX یک ماژول امضا شدهی Android Mainline. این یک رشتهی هگز از خلاصهی SHA256 کل فایل است.
- توضیح نوع هش بالا. این یک رشته است.
- نام بستهی ماژول. این یک رشته است.
- شماره نسخه ( versionCode ) ماژول. این یک عدد صحیح غیر صفر است.
قالب یک ورودی لاگ، الحاق چهار قطعه اطلاعات با یک کاراکتر خط جدید ( \n ) است، همانطور که در شکل زیر نشان داده شده است:
hash\nhash_description\npackage_name\npackage_version\n
از آنجایی که یک ماژول اصلی میتواند یک فایل APK یا APEX باشد، توضیحات هش میتواند SHA256(APK) یا SHA256(APEX) باشد.