بهترین شیوه های امنیت سیستم، بهترین شیوه های امنیت سیستم، بهترین شیوه های امنیت سیستم

با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

این بخش حاوی توصیه هایی برای اطمینان از امنیت سیستم عامل و دستگاه های اصلی اندروید است.

احراز هویت بیومتریک

داده های بیومتریک را برای احراز هویت کاربر به دقت دریافت، ذخیره و پردازش کنید. شما باید:

• قبل از استفاده از هر شکل دیگری از احراز هویت (از جمله بیومتریک) روش احراز هویت اولیه را اجباری کنید.
• هنگام استفاده از روش‌های بیومتریک غیرفعال، مانند تشخیص چهره، برای تراکنش‌هایی (مثلاً پرداخت‌ها) که شامل کلیدهای مرتبط با احراز هویت است، به تأیید صریح نیاز دارید تا نشان دهد قصد دارید.
• هر 72 ساعت به روش احراز هویت اولیه نیاز دارید.
• از یک خط لوله کاملاً ایمن برای همه داده‌های بیومتریک و مدیریت استفاده کنید.
• هرگز داده های بیومتریک (از جمله اندازه گیری حسگر خام و ویژگی های مشتق شده) را خارج از دستگاه ارسال نکنید. در صورت امکان، این داده ها را در یک محیط ایزوله ایمن مانند محیط اجرای مورد اعتماد (TEE) یا Secure Element نگهداری کنید.

دستگاه‌های دارای مشخصات بیومتریک باید از BiometricPrompt API پشتیبانی کنند، که یک رابط مشترک و ثابت برای توسعه‌دهندگان برنامه‌ها ارائه می‌کند تا از احراز هویت مبتنی بر بیومتریک در برنامه‌های خود استفاده کنند. فقط بیومتریک قوی می‌تواند با BiometricPrompt ادغام شود و ادغام‌ها باید از دستورالعمل‌های سند تعریف سازگاری Android (CDD) پیروی کنند.

برای دستورالعمل‌های بیومتریک بیشتر، دستورالعمل‌های اجرای بیومتریک HAL را ببینید.

SELinux

SELinux تعریف و اجرای بسیاری از مدل های امنیتی اندروید را ارائه می دهد. استفاده صحیح از SELinux برای امنیت دستگاه های اندرویدی بسیار مهم است و می تواند به کاهش تأثیر آسیب پذیری های امنیتی کمک کند. به همین دلیل همه دستگاه های اندرویدی باید یک خط مشی قوی SELinux را اجرا کنند.

• سیاست کمترین امتیاز را اجرا کنید.
• از دادن مجوزهای CAP_DAC_OVERRIDE ، CAP_SYS_ADMIN ، و CAP_NET_ADMIN خودداری کنید.
• داده های سیستم را به کارت SD وارد نکنید.
• از انواع ارائه شده برای دسترسی به درایور استفاده کنید، مانند gpu_device ، audio_device و غیره.
• از نام های معنی دار برای پردازش ها، فایل ها و انواع SELinux استفاده کنید.
  • اطمینان حاصل کنید که از برچسب‌های پیش‌فرض استفاده نمی‌شود و دسترسی به آنها اعطا نمی‌شود.
• خط‌مشی مخصوص دستگاه باید 5 تا 10 درصد از خط‌مشی کلی اجرا شده روی دستگاه را تشکیل دهد. سفارشی‌سازی‌ها در محدوده 20%+ تقریباً مطمئناً حاوی دامنه‌های دارای امتیاز بیش از حد و خط‌مشی مرده هستند. سیاست بزرگ غیرضروری حافظه را هدر می دهد، فضای دیسک را با نیاز به تصویر بوت بزرگتر هدر می دهد و بر زمان جستجوی خط مشی زمان اجرا تأثیر منفی می گذارد.

بارگذاری پویا سیاست SELinux

خط مشی SELinux را به صورت پویا در دستگاه های Android بارگیری نکنید. انجام این کار می تواند منجر به مشکلاتی مانند:

• جلوگیری از پذیرش وصله های امنیتی حیاتی.
• افشای توانایی روت کردن دستگاه از طریق بارگذاری مجدد خط مشی ها.
• افشای یک بردار برای حملات انسان در وسط علیه به روز رسانی سیاست.
• به دلیل خطاهای به‌روزرسانی خط‌مشی، دستگاه‌های آجری ایجاد می‌شوند.

درهای پشتی

برنامه‌های اندرویدی نباید هیچ درب پشتی یا راه‌هایی برای دسترسی به سیستم یا داده‌هایی داشته باشند که مکانیسم‌های امنیتی عادی را دور بزنند. این شامل عیب‌یابی، اشکال‌زدایی، توسعه یا تعمیر ضمانت‌نامه دسترسی ویژه است که توسط اسرار شناخته شده برای توسعه‌دهنده بسته شده است. برای جلوگیری از درهای پشتی:

• همه برنامه های شخص ثالث را با استفاده از ابزار اسکن آسیب پذیری برنامه های شناخته شده در صنعت اسکن کنید.
• بررسی کد همه کدهای دارای دسترسی حساس، از جمله کتابخانه های شخص ثالث را انجام دهید.
• با آپلود برنامه‌ها در Google Play برای اسکن، از Google Play Protect استفاده کنید. می‌توانید برنامه‌ها را برای اسکن بدون انتشار در Google Play آپلود کنید.
• ابزارهای عیب‌یابی یا تعمیر را در نسخه‌های منتشر شده از قبل بارگذاری نکنید. این ابزارها را فقط بر حسب تقاضا برای حل مشکلات خاص نصب کنید. به‌علاوه، این ابزارها نباید بر اساس داده‌های خاص حساب کار کنند یا آن را آپلود کنند.

ابزار توسعه

ابزارهای توسعه، مانند ابزارهای اشکال زدایی، آزمایش و تشخیص، اغلب می توانند با آشکار کردن نحوه عملکرد و داده هایی که جمع آوری می کنند، شکاف های امنیتی ناخواسته ای را در دستگاه شما ایجاد کنند. برای اطمینان از اینکه ابزارهای توسعه آن را وارد ساخت‌های تولیدی نمی‌کنند:

• قبل از استفاده از تصویر سیستم، فهرست سیاهی از هش‌های ابزار اشکال‌زدایی و آزمایش داخلی ایجاد کنید و ساخت‌های این APK را اسکن کنید.
• با استفاده از ابزار اسکن آسیب پذیری برنامه های شناخته شده در صنعت، تمام برنامه های شخص اول را اسکن کنید.
• یک شرکت تست امنیت برنامه شخص ثالث را استخدام کنید تا همه برنامه‌های تشخیصی مهم روی دستگاه را قبل از هر به‌روزرسانی مهمی ارزیابی کند، به‌خصوص اگر برنامه توسط شخص ثالثی توسعه داده شده باشد.
• اطمینان حاصل کنید که فقط کاربر می تواند ابزار را به صورت شفاهی یا از طریق چت در طول جلسه پشتیبانی فعال کند. مصنوعات رضایت را ذخیره کنید و پس از جمع آوری اطلاعات تشخیصی لازم، ابزار را غیرفعال کنید.
• سابقه استفاده از این ابزار را در یک گزارش قابل دسترسی توسط کاربر در حساب حامل خود ذخیره کنید.
• اطمینان حاصل کنید که هرگونه اطلاعات شناسایی شخصی (PII) یا داده‌های تله‌متری دستگاه جمع‌آوری‌شده توسط این ابزار مشمول شیوه‌های ناشناس، حفظ و حذف مربوط به کشور است. فقط داده های مربوط به تماس پشتیبانی باید جمع آوری شود. این داده ها باید پس از هر تماس حذف شوند.
• اطمینان حاصل کنید که تکنیک‌هایی که می‌توانند برای نرم‌افزارهای جاسوسی استفاده شوند، مانند ثبت با ضربه زدن به کلید، استفاده از میکروفون، یا استفاده از دوربین، بدون رضایت صریح کاربر استفاده نمی‌شوند. برنامه‌هایی که از این روش‌های بالقوه تهاجمی به حریم خصوصی استفاده می‌کنند باید به‌طور واضح همراه با خط‌مشی رازداری که کاربر باید با آن موافقت کند، افشا شود. برنامه هایی مانند این نباید بدون رضایت صریح کاربر فعال شوند.

در اینجا چند پیشنهاد اضافی وجود دارد که باید هنگام اجرای افشا و رضایت به آنها اشاره کرد:

افشای درون برنامه ای

• استفاده عادی از برنامه را مستقیماً در برنامه نمایش دهید. لازم نیست کاربر به منو یا تنظیمات پیمایش کند.
• نوع داده های جمع آوری شده را شرح دهید و نحوه استفاده از داده ها را توضیح دهید.
• در حالت ایده آل، این اطلاعات را در خط مشی رازداری یا شرایط خدمات جاسازی نکنید. آن را با سایر افشاگری‌های غیر مرتبط با جمع‌آوری داده‌های شخصی یا حساس وارد نکنید.

درخواست رضایت

• رضایت باید مثبت باشد. پیمایش دور از افشا، از جمله دور زدن یا فشار دادن دکمه بازگشت یا صفحه اصلی را به عنوان رضایت تلقی نکنید.
• گفتگوی رضایت را به صورت واضح و بدون ابهام ارائه دهید.
• برای پذیرش، به اقدام مثبت کاربر، مانند ضربه زدن برای پذیرش یا گفتن فرمان، نیاز دارید.
• قبل از کسب رضایت نامه، داده های شخصی یا حساس را جمع آوری نکنید.
• از پیام‌های رد خودکار یا منقضی شده استفاده نکنید.

قابلیت تعبیه شده در AOSP

تعبیه عملکرد اضافی در AOSP اغلب می تواند رفتار و پیامدهای غیرمنتظره ای داشته باشد. با احتیاط ادامه دهید

• اطمینان حاصل کنید که اگر کاربر می‌خواهد از برنامه‌های پیش‌فرض مختلف (مثلاً موتور جستجو، مرورگر وب، راه‌انداز) استفاده کند و داده‌های ارسال شده را از دستگاه فاش کند، از آن خواسته می‌شود.
• اطمینان حاصل کنید که AOSP APK با گواهی AOSP امضا شده است.
• تست‌های رگرسیون را اجرا کنید و یک گزارش تغییرات نگه دارید تا مشخص کنید آیا AOSP APK کد اضافه شده است یا خیر.

به روز رسانی های امنیتی

دستگاه های اندرویدی باید حداقل تا دو سال پس از راه اندازی، پشتیبانی امنیتی مداوم دریافت کنند. این شامل دریافت به‌روزرسانی‌های منظم است که آسیب‌پذیری‌های امنیتی شناخته شده را برطرف می‌کند.

• با شرکای سخت افزاری مانند فروشندگان SoC خود کار کنید تا توافق نامه های پشتیبانی مناسب را برای همه اجزای دستگاه Android خود تنظیم کنید.
• اطمینان حاصل کنید که به‌روزرسانی‌های امنیتی را می‌توان با حداقل تعامل کاربر نصب کرد تا احتمال پذیرش و نصب به‌روزرسانی‌ها در دستگاه اندرویدی توسط کاربران افزایش یابد. اجرای به‌روزرسانی‌های سیستم بدون درز یا یک ویژگی امنیتی معادل اکیداً توصیه می‌شود.
• اطمینان حاصل کنید که الزامات تجمعی وصله امنیتی Android (SPL) را همانطور که در بولتن امنیتی Android اعلام شده است، درک می کنید. به عنوان مثال، دستگاه‌هایی که از سطح وصله امنیتی 01-02-2018 استفاده می‌کنند، باید تمام مشکلات مرتبط با آن سطح وصله امنیتی و همچنین رفع تمام مشکلات گزارش‌شده در همه بولتن‌های امنیتی قبلی را شامل شوند.

به روز رسانی هسته پویا

اجزای حیاتی سیستم را به صورت پویا تغییر ندهید. در حالی که برخی تحقیقات نشان می دهد که به روز رسانی هسته پویا به محافظت در برابر تهدیدات اضطراری کمک می کند، هزینه ارزیابی شده در حال حاضر بیشتر از مزایای آن است. در عوض، یک روش به روز رسانی OTA قوی ایجاد کنید تا به سرعت محافظت های آسیب پذیری را توزیع کنید.

مدیریت کلید

سیاست ها و شیوه های مدیریت کلید را برای اطمینان از امنیت کلیدهای امضاء حفظ کنید.

• کلیدهای امضا را با طرف های خارجی به اشتراک نگذارید.
• اگر یک کلید امضا به خطر افتاده است، یک کلید جدید ایجاد کنید و همه برنامه‌ها را دوبار امضا کنید.
• همه کلیدها را در سخت‌افزار یا سرویس‌های ماژول با امنیت بالا که برای دسترسی به عوامل متعددی نیاز دارند، ذخیره کنید.

امضای تصویر سیستم

امضای تصویر سیستم برای تعیین یکپارچگی دستگاه بسیار مهم است.

• دستگاه‌ها را با یک کلید شناخته شده برای عموم امضا نکنید.
• کلیدهای امضای دستگاه را به روشی مطابق با شیوه‌های استاندارد صنعتی برای مدیریت کلیدهای حساس مدیریت کنید، از جمله یک ماژول امنیتی سخت‌افزار (HSM) که دسترسی محدود و قابل بازرسی را فراهم می‌کند.

بوت لودرهای قابل باز شدن

بسیاری از دستگاه‌های اندرویدی از باز کردن قفل پشتیبانی می‌کنند، که به مالک دستگاه امکان می‌دهد پارتیشن سیستم را تغییر دهد یا یک سیستم عامل سفارشی نصب کند. موارد استفاده رایج شامل نصب تصویر سیستم شخص ثالث و انجام توسعه در سطح سیستم بر روی دستگاه است. به عنوان مثال، برای باز کردن قفل تصویر سیستم در Google Nexus یا Pixel، کاربر می‌تواند fastboot oem unlock اجرا کند که این پیام را نشان می‌دهد:

به عنوان بهترین روش، دستگاه‌های اندرویدی قابل باز شدن باید قبل از باز شدن قفل، همه داده‌های کاربر را به‌طور ایمن پاک کنند. عدم حذف صحیح همه داده‌ها هنگام باز کردن قفل ممکن است به یک مهاجم نزدیک به فیزیکی اجازه دسترسی غیرمجاز به داده‌های محرمانه کاربر Android را بدهد. برای جلوگیری از افشای اطلاعات کاربر، دستگاهی که از باز کردن قفل پشتیبانی می کند باید آن را به درستی پیاده سازی کند.

• پس از تأیید فرمان باز کردن قفل توسط کاربر، دستگاه باید فوراً پاک کردن اطلاعات را شروع کند. پرچم unlocked نباید تا زمانی که حذف ایمن کامل شود تنظیم شود.
• اگر حذف ایمن نمی تواند تکمیل شود، دستگاه باید در حالت قفل بماند.
• اگر توسط دستگاه بلوک زیرین پشتیبانی می شود، باید ioctl(BLKSECDISCARD) یا معادل آن استفاده شود. برای دستگاه‌های کارت چند رسانه‌ای (eMMC) تعبیه‌شده، این به معنای استفاده از فرمان پاک کردن امن یا برش امن است. برای eMMC 4.5 و جدیدتر، این به معنای استفاده از یک Erase یا Trim معمولی و به دنبال آن یک عملیات Sanitize است.
• اگر BLKSECDISCARD توسط دستگاه بلوک زیرین پشتیبانی نمی شود، باید به جای آن از ioctl(BLKDISCARD) استفاده شود. در دستگاه‌های eMMC، این یک عملیات Trim معمولی است.
• اگر BLKDISCARD پشتیبانی نمی‌شود، بازنویسی دستگاه‌های بلوک با تمام صفرها قابل قبول است.
• یک کاربر باید این گزینه را داشته باشد که قبل از فلش کردن پارتیشن، اطلاعات کاربر را پاک کند. برای مثال، دستگاه‌های Nexus از فرمان fastboot oem lock برای پاک کردن اطلاعات کاربر استفاده می‌کنند.
• یک دستگاه ممکن است از طریق eFuse یا مکانیزم مشابه، قفل و/یا قفل مجدد دستگاه را ضبط کند. با این حال، ما قویاً توصیه می کنیم که قفل مجدد بوت لودر با بازنشانی کارخانه ای بعدی باید عملکرد کامل دستگاه را بازیابی کند.

این الزامات تضمین می کند که تمام داده ها پس از اتمام عملیات باز کردن قفل از بین می روند. عدم اجرای این حفاظت ها یک آسیب پذیری امنیتی در سطح متوسط ​​تلقی می شود.

دستگاهی که قفل آن باز است ممکن است متعاقباً با استفاده از فرمان fastboot oem lock قفل مجدد شود. قفل کردن بوت لودر همان حفاظتی را از اطلاعات کاربر با سیستم عامل سفارشی جدید فراهم می کند که در سیستم عامل اصلی سازنده دستگاه موجود بود (به عنوان مثال، اگر قفل دستگاه دوباره باز شود، اطلاعات کاربر پاک می شود).

دستگاه در حال آزمایش

دستگاه ها باید قبل از حمل و نقل توسط یک پنتستر ذیصلاح بررسی شوند. Pentesting باید مشخص کند که دستگاه از دستورالعمل‌های امنیتی ارائه‌شده در اینجا و همچنین دستورالعمل‌های امنیتی OEM داخلی پیروی می‌کند.

تست امنیتی

از ابزارهای تست امنیتی ارائه شده توسط AOSP استفاده کنید. به طور خاص

• از ابزارهای ایمنی حافظه در طول توسعه استفاده کنید: از MTE در جایی که پشتیبانی می شود (ARMv9 و بالاتر) و از HWASan در جایی که پشتیبانی نمی شود استفاده کنید. با فعال بودن این ابزار تا حد امکان تست ها را اجرا کنید.
• از GWP-ASan و KFENCE در تولید، برای تشخیص احتمالی مسائل ایمنی حافظه استفاده کنید.

این بخش حاوی توصیه هایی برای اطمینان از امنیت سیستم عامل و دستگاه های اصلی اندروید است.

احراز هویت بیومتریک

داده های بیومتریک را برای احراز هویت کاربر به دقت دریافت، ذخیره و پردازش کنید. شما باید:

• قبل از استفاده از هر شکل دیگری از احراز هویت (از جمله بیومتریک) روش احراز هویت اولیه را اجباری کنید.
• هنگام استفاده از روش‌های بیومتریک غیرفعال، مانند تشخیص چهره، برای تراکنش‌هایی (مثلاً پرداخت‌ها) که شامل کلیدهای مرتبط با احراز هویت است، به تأیید صریح نیاز دارید تا نشان دهد قصد دارید.
• هر 72 ساعت به روش احراز هویت اولیه نیاز دارید.
• از یک خط لوله کاملاً ایمن برای همه داده‌های بیومتریک و مدیریت استفاده کنید.
• هرگز داده های بیومتریک (از جمله اندازه گیری حسگر خام و ویژگی های مشتق شده) را خارج از دستگاه ارسال نکنید. در صورت امکان، این داده ها را در یک محیط ایزوله ایمن مانند محیط اجرای مورد اعتماد (TEE) یا Secure Element نگهداری کنید.

دستگاه‌های دارای مشخصات بیومتریک باید از BiometricPrompt API پشتیبانی کنند، که یک رابط مشترک و ثابت برای توسعه‌دهندگان برنامه‌ها ارائه می‌کند تا از احراز هویت مبتنی بر بیومتریک در برنامه‌های خود استفاده کنند. فقط بیومتریک قوی می‌تواند با BiometricPrompt ادغام شود و ادغام‌ها باید از دستورالعمل‌های سند تعریف سازگاری Android (CDD) پیروی کنند.

برای دستورالعمل‌های بیومتریک بیشتر، دستورالعمل‌های اجرای بیومتریک HAL را ببینید.

SELinux

SELinux تعریف و اجرای بسیاری از مدل های امنیتی اندروید را ارائه می دهد. استفاده صحیح از SELinux برای امنیت دستگاه های اندرویدی بسیار مهم است و می تواند به کاهش تأثیر آسیب پذیری های امنیتی کمک کند. به همین دلیل همه دستگاه های اندرویدی باید یک خط مشی قوی SELinux را اجرا کنند.

• سیاست کمترین امتیاز را اجرا کنید.
• از دادن مجوزهای CAP_DAC_OVERRIDE ، CAP_SYS_ADMIN ، و CAP_NET_ADMIN خودداری کنید.
• داده های سیستم را به کارت SD وارد نکنید.
• از انواع ارائه شده برای دسترسی به درایور استفاده کنید، مانند gpu_device ، audio_device و غیره.
• از نام های معنی دار برای پردازش ها، فایل ها و انواع SELinux استفاده کنید.
  • اطمینان حاصل کنید که از برچسب‌های پیش‌فرض استفاده نمی‌شود و دسترسی به آنها اعطا نمی‌شود.
• خط‌مشی مخصوص دستگاه باید 5 تا 10 درصد از خط‌مشی کلی اجرا شده روی دستگاه را تشکیل دهد. سفارشی‌سازی‌ها در محدوده 20%+ تقریباً مطمئناً حاوی دامنه‌های دارای امتیاز بیش از حد و خط‌مشی مرده هستند. سیاست بزرگ غیرضروری حافظه را هدر می دهد، فضای دیسک را با نیاز به تصویر بوت بزرگتر هدر می دهد و بر زمان جستجوی خط مشی زمان اجرا تأثیر منفی می گذارد.

بارگذاری پویا سیاست SELinux

خط مشی SELinux را به صورت پویا در دستگاه های Android بارگیری نکنید. انجام این کار می تواند منجر به مشکلاتی مانند:

• جلوگیری از پذیرش وصله های امنیتی حیاتی.
• افشای توانایی روت کردن دستگاه از طریق بارگذاری مجدد خط مشی ها.
• افشای یک بردار برای حملات انسان در وسط علیه به روز رسانی سیاست.
• به دلیل خطاهای به‌روزرسانی خط‌مشی، دستگاه‌های آجری ایجاد می‌شوند.

درهای پشتی

برنامه‌های اندرویدی نباید هیچ درب پشتی یا راه‌هایی برای دسترسی به سیستم یا داده‌هایی داشته باشند که مکانیسم‌های امنیتی عادی را دور بزنند. این شامل عیب‌یابی، اشکال‌زدایی، توسعه یا تعمیر ضمانت‌نامه دسترسی ویژه است که توسط اسرار شناخته شده برای توسعه‌دهنده بسته شده است. برای جلوگیری از درهای پشتی:

• همه برنامه های شخص ثالث را با استفاده از ابزار اسکن آسیب پذیری برنامه های شناخته شده در صنعت اسکن کنید.
• بررسی کد همه کدهای دارای دسترسی حساس، از جمله کتابخانه های شخص ثالث را انجام دهید.
• با آپلود برنامه‌ها در Google Play برای اسکن، از Google Play Protect استفاده کنید. می‌توانید برنامه‌ها را برای اسکن بدون انتشار در Google Play آپلود کنید.
• ابزارهای عیب‌یابی یا تعمیر را در نسخه‌های منتشر شده از قبل بارگذاری نکنید. این ابزارها را فقط بر حسب تقاضا برای حل مشکلات خاص نصب کنید. به‌علاوه، این ابزارها نباید بر اساس داده‌های خاص حساب کار کنند یا آن را آپلود کنند.

ابزار توسعه

ابزارهای توسعه، مانند ابزارهای اشکال زدایی، آزمایش و تشخیص، اغلب می توانند با آشکار کردن نحوه عملکرد و داده هایی که جمع آوری می کنند، شکاف های امنیتی ناخواسته ای را در دستگاه شما ایجاد کنند. برای اطمینان از اینکه ابزارهای توسعه آن را وارد ساخت‌های تولیدی نمی‌کنند:

• قبل از استفاده از تصویر سیستم، فهرست سیاهی از هش‌های ابزار اشکال‌زدایی و آزمایش داخلی ایجاد کنید و ساخت‌های این APK را اسکن کنید.
• با استفاده از ابزار اسکن آسیب پذیری برنامه های شناخته شده در صنعت، تمام برنامه های شخص اول را اسکن کنید.
• یک شرکت تست امنیت برنامه شخص ثالث را استخدام کنید تا همه برنامه‌های تشخیصی مهم روی دستگاه را قبل از هر به‌روزرسانی مهمی ارزیابی کند، به‌خصوص اگر برنامه توسط شخص ثالثی توسعه داده شده باشد.
• اطمینان حاصل کنید که فقط کاربر می تواند ابزار را به صورت شفاهی یا از طریق چت در طول جلسه پشتیبانی فعال کند. مصنوعات رضایت را ذخیره کنید و پس از جمع آوری اطلاعات تشخیصی لازم، ابزار را غیرفعال کنید.
• سابقه استفاده از این ابزار را در یک گزارش قابل دسترسی توسط کاربر در حساب حامل خود ذخیره کنید.
• اطمینان حاصل کنید که هرگونه اطلاعات شناسایی شخصی (PII) یا داده‌های تله‌متری دستگاه جمع‌آوری‌شده توسط این ابزار مشمول شیوه‌های ناشناس، حفظ و حذف مربوط به کشور است. فقط داده های مربوط به تماس پشتیبانی باید جمع آوری شود. این داده ها باید پس از هر تماس حذف شوند.
• اطمینان حاصل کنید که تکنیک‌هایی که می‌توانند برای نرم‌افزارهای جاسوسی استفاده شوند، مانند ثبت با ضربه زدن به کلید، استفاده از میکروفون، یا استفاده از دوربین، بدون رضایت صریح کاربر استفاده نمی‌شوند. برنامه‌هایی که از این روش‌های بالقوه تهاجمی به حریم خصوصی استفاده می‌کنند باید به‌طور واضح همراه با خط‌مشی رازداری که کاربر باید با آن موافقت کند، افشا شود. برنامه هایی مانند این نباید بدون رضایت صریح کاربر فعال شوند.

در اینجا چند پیشنهاد اضافی وجود دارد که باید هنگام اجرای افشا و رضایت به آنها اشاره کرد:

افشای درون برنامه ای

• استفاده عادی از برنامه را مستقیماً در برنامه نمایش دهید. لازم نیست کاربر به منو یا تنظیمات پیمایش کند.
• نوع داده های جمع آوری شده را شرح دهید و نحوه استفاده از داده ها را توضیح دهید.
• در حالت ایده آل، این اطلاعات را در خط مشی رازداری یا شرایط خدمات جاسازی نکنید. آن را با سایر افشاگری‌های غیر مرتبط با جمع‌آوری داده‌های شخصی یا حساس وارد نکنید.

درخواست رضایت

• رضایت باید مثبت باشد. پیمایش دور از افشا، از جمله دور زدن یا فشار دادن دکمه بازگشت یا صفحه اصلی را به عنوان رضایت تلقی نکنید.
• گفتگوی رضایت را به صورت واضح و بدون ابهام ارائه دهید.
• برای پذیرش، به اقدام مثبت کاربر، مانند ضربه زدن برای پذیرش یا گفتن فرمان، نیاز دارید.
• قبل از کسب رضایت نامه، داده های شخصی یا حساس را جمع آوری نکنید.
• از پیام‌های رد خودکار یا منقضی شده استفاده نکنید.

قابلیت تعبیه شده در AOSP

تعبیه عملکرد اضافی در AOSP اغلب می تواند رفتار و پیامدهای غیرمنتظره ای داشته باشد. با احتیاط ادامه دهید

• اطمینان حاصل کنید که اگر کاربر می‌خواهد از برنامه‌های پیش‌فرض مختلف (مثلاً موتور جستجو، مرورگر وب، راه‌انداز) استفاده کند و داده‌های ارسال شده را از دستگاه فاش کند، از آن خواسته می‌شود.
• اطمینان حاصل کنید که AOSP APK با گواهی AOSP امضا شده است.
• تست‌های رگرسیون را اجرا کنید و یک گزارش تغییرات نگه دارید تا مشخص کنید آیا AOSP APK کد اضافه شده است یا خیر.

به روز رسانی های امنیتی

دستگاه های اندرویدی باید حداقل تا دو سال پس از راه اندازی، پشتیبانی امنیتی مداوم دریافت کنند. این شامل دریافت به‌روزرسانی‌های منظم است که آسیب‌پذیری‌های امنیتی شناخته شده را برطرف می‌کند.

• با شرکای سخت افزاری مانند فروشندگان SoC خود کار کنید تا توافق نامه های پشتیبانی مناسب را برای همه اجزای دستگاه Android خود تنظیم کنید.
• اطمینان حاصل کنید که به‌روزرسانی‌های امنیتی را می‌توان با حداقل تعامل کاربر نصب کرد تا احتمال پذیرش و نصب به‌روزرسانی‌ها در دستگاه اندرویدی توسط کاربران افزایش یابد. اجرای به‌روزرسانی‌های سیستم بدون درز یا یک ویژگی امنیتی معادل اکیداً توصیه می‌شود.
• اطمینان حاصل کنید که الزامات تجمعی وصله امنیتی Android (SPL) را همانطور که در بولتن امنیتی Android اعلام شده است، درک می کنید. به عنوان مثال، دستگاه‌هایی که از سطح وصله امنیتی 01-02-2018 استفاده می‌کنند، باید تمام مشکلات مرتبط با آن سطح وصله امنیتی و همچنین رفع تمام مشکلات گزارش‌شده در همه بولتن‌های امنیتی قبلی را شامل شوند.

به روز رسانی هسته پویا

اجزای حیاتی سیستم را به صورت پویا تغییر ندهید. در حالی که برخی تحقیقات نشان می دهد که به روز رسانی هسته پویا به محافظت در برابر تهدیدات اضطراری کمک می کند، هزینه ارزیابی شده در حال حاضر بیشتر از مزایای آن است. در عوض، یک روش به روز رسانی OTA قوی ایجاد کنید تا به سرعت محافظت های آسیب پذیری را توزیع کنید.

مدیریت کلید

سیاست ها و شیوه های مدیریت کلید را برای اطمینان از امنیت کلیدهای امضاء حفظ کنید.

• کلیدهای امضا را با طرف های خارجی به اشتراک نگذارید.
• اگر یک کلید امضا به خطر افتاده است، یک کلید جدید ایجاد کنید و همه برنامه‌ها را دوبار امضا کنید.
• همه کلیدها را در سخت‌افزار یا سرویس‌های ماژول با امنیت بالا که برای دسترسی به عوامل متعددی نیاز دارند، ذخیره کنید.

امضای تصویر سیستم

امضای تصویر سیستم برای تعیین یکپارچگی دستگاه بسیار مهم است.

• دستگاه‌ها را با یک کلید شناخته شده برای عموم امضا نکنید.
• کلیدهای امضای دستگاه را به روشی مطابق با شیوه‌های استاندارد صنعتی برای مدیریت کلیدهای حساس مدیریت کنید، از جمله یک ماژول امنیتی سخت‌افزار (HSM) که دسترسی محدود و قابل بازرسی را فراهم می‌کند.

بوت لودرهای قابل باز شدن

بسیاری از دستگاه‌های اندرویدی از باز کردن قفل پشتیبانی می‌کنند، که به مالک دستگاه امکان می‌دهد پارتیشن سیستم را تغییر دهد یا یک سیستم عامل سفارشی نصب کند. موارد استفاده رایج شامل نصب تصویر سیستم شخص ثالث و انجام توسعه در سطح سیستم بر روی دستگاه است. به عنوان مثال، برای باز کردن قفل تصویر سیستم در Google Nexus یا Pixel، کاربر می‌تواند fastboot oem unlock اجرا کند که این پیام را نشان می‌دهد:

به عنوان بهترین روش، دستگاه‌های اندرویدی قابل باز شدن باید قبل از باز شدن قفل، همه داده‌های کاربر را به‌طور ایمن پاک کنند. عدم حذف صحیح همه داده‌ها هنگام باز کردن قفل ممکن است به یک مهاجم نزدیک به فیزیکی اجازه دسترسی غیرمجاز به داده‌های محرمانه کاربر Android را بدهد. برای جلوگیری از افشای اطلاعات کاربر، دستگاهی که از باز کردن قفل پشتیبانی می کند باید آن را به درستی پیاده سازی کند.

• پس از تأیید فرمان باز کردن قفل توسط کاربر، دستگاه باید فوراً پاک کردن اطلاعات را شروع کند. پرچم unlocked نباید تا زمانی که حذف ایمن کامل شود تنظیم شود.
• اگر حذف ایمن نمی تواند تکمیل شود، دستگاه باید در حالت قفل بماند.
• اگر توسط دستگاه بلوک زیرین پشتیبانی می شود، باید ioctl(BLKSECDISCARD) یا معادل آن استفاده شود. برای دستگاه‌های کارت چند رسانه‌ای (eMMC) تعبیه‌شده، این به معنای استفاده از فرمان پاک کردن امن یا برش امن است. برای eMMC 4.5 و جدیدتر، این به معنای استفاده از یک Erase یا Trim معمولی و به دنبال آن یک عملیات Sanitize است.
• اگر BLKSECDISCARD توسط دستگاه بلوک زیرین پشتیبانی نمی شود، باید به جای آن از ioctl(BLKDISCARD) استفاده شود. در دستگاه‌های eMMC، این یک عملیات Trim معمولی است.
• اگر BLKDISCARD پشتیبانی نمی‌شود، بازنویسی دستگاه‌های بلوک با تمام صفرها قابل قبول است.
• یک کاربر باید این گزینه را داشته باشد که قبل از فلش کردن پارتیشن، اطلاعات کاربر را پاک کند. برای مثال، دستگاه‌های Nexus از فرمان fastboot oem lock برای پاک کردن اطلاعات کاربر استفاده می‌کنند.
• یک دستگاه ممکن است از طریق eFuse یا مکانیزم مشابه، قفل و/یا قفل مجدد دستگاه را ضبط کند. با این حال، ما قویاً توصیه می کنیم که قفل مجدد بوت لودر با بازنشانی کارخانه ای بعدی باید عملکرد کامل دستگاه را بازیابی کند.

این الزامات تضمین می کند که تمام داده ها پس از اتمام عملیات باز کردن قفل از بین می روند. عدم اجرای این حفاظت ها یک آسیب پذیری امنیتی در سطح متوسط ​​تلقی می شود.

دستگاهی که قفل آن باز است ممکن است متعاقباً با استفاده از فرمان fastboot oem lock قفل مجدد شود. قفل کردن بوت لودر همان حفاظتی را از اطلاعات کاربر با سیستم عامل سفارشی جدید فراهم می کند که در سیستم عامل اصلی سازنده دستگاه موجود بود (به عنوان مثال، اگر قفل دستگاه دوباره باز شود، اطلاعات کاربر پاک می شود).

دستگاه در حال آزمایش

دستگاه ها باید قبل از حمل و نقل توسط یک پنتستر ذیصلاح بررسی شوند. Pentesting باید مشخص کند که دستگاه از دستورالعمل‌های امنیتی ارائه‌شده در اینجا و همچنین دستورالعمل‌های امنیتی OEM داخلی پیروی می‌کند.

تست امنیتی

از ابزارهای تست امنیتی ارائه شده توسط AOSP استفاده کنید. به طور خاص

• از ابزارهای ایمنی حافظه در طول توسعه استفاده کنید: از MTE در جایی که پشتیبانی می شود (ARMv9 و بالاتر) و از HWASan در جایی که پشتیبانی نمی شود استفاده کنید. با فعال بودن این ابزار تا حد امکان تست ها را اجرا کنید.
• از GWP-ASan و KFENCE در تولید، برای تشخیص احتمالی مسائل ایمنی حافظه استفاده کنید.

این بخش حاوی توصیه هایی برای اطمینان از امنیت سیستم عامل و دستگاه های اصلی اندروید است.

احراز هویت بیومتریک

داده های بیومتریک را برای احراز هویت کاربر به دقت دریافت، ذخیره و پردازش کنید. شما باید:

• قبل از استفاده از هر شکل دیگری از احراز هویت (از جمله بیومتریک) روش احراز هویت اولیه را اجباری کنید.
• هنگام استفاده از روش‌های بیومتریک غیرفعال، مانند تشخیص چهره، برای تراکنش‌هایی (مثلاً پرداخت‌ها) که شامل کلیدهای مرتبط با احراز هویت است، به تأیید صریح نیاز دارید تا نشان دهد قصد دارید.
• هر 72 ساعت به روش احراز هویت اولیه نیاز دارید.
• از یک خط لوله کاملاً ایمن برای همه داده‌های بیومتریک و مدیریت استفاده کنید.
• هرگز داده های بیومتریک (از جمله اندازه گیری حسگر خام و ویژگی های مشتق شده) را خارج از دستگاه ارسال نکنید. در صورت امکان، این داده ها را در یک محیط ایزوله ایمن مانند محیط اجرای مورد اعتماد (TEE) یا Secure Element نگهداری کنید.

دستگاه‌های دارای مشخصات بیومتریک باید از BiometricPrompt API پشتیبانی کنند، که یک رابط مشترک و ثابت برای توسعه‌دهندگان برنامه‌ها ارائه می‌کند تا از احراز هویت مبتنی بر بیومتریک در برنامه‌های خود استفاده کنند. فقط بیومتریک قوی می‌تواند با BiometricPrompt ادغام شود و ادغام‌ها باید از دستورالعمل‌های سند تعریف سازگاری Android (CDD) پیروی کنند.

برای دستورالعمل‌های بیومتریک بیشتر، دستورالعمل‌های اجرای بیومتریک HAL را ببینید.

SELinux

SELinux تعریف و اجرای بسیاری از مدل های امنیتی اندروید را ارائه می دهد. استفاده صحیح از SELinux برای امنیت دستگاه های اندرویدی بسیار مهم است و می تواند به کاهش تأثیر آسیب پذیری های امنیتی کمک کند. به همین دلیل همه دستگاه های اندرویدی باید یک خط مشی قوی SELinux را اجرا کنند.

• سیاست کمترین امتیاز را اجرا کنید.
• از دادن مجوزهای CAP_DAC_OVERRIDE ، CAP_SYS_ADMIN ، و CAP_NET_ADMIN خودداری کنید.
• داده های سیستم را به کارت SD وارد نکنید.
• از انواع ارائه شده برای دسترسی به درایور استفاده کنید، مانند gpu_device ، audio_device و غیره.
• از نام های معنی دار برای پردازش ها، فایل ها و انواع SELinux استفاده کنید.
  • اطمینان حاصل کنید که از برچسب‌های پیش‌فرض استفاده نمی‌شود و دسترسی به آنها اعطا نمی‌شود.
• خط‌مشی مخصوص دستگاه باید 5 تا 10 درصد از خط‌مشی کلی اجرا شده روی دستگاه را تشکیل دهد. سفارشی‌سازی‌ها در محدوده 20%+ تقریباً مطمئناً حاوی دامنه‌های دارای امتیاز بیش از حد و خط‌مشی مرده هستند. سیاست بزرگ غیرضروری حافظه را هدر می دهد، فضای دیسک را با نیاز به تصویر بوت بزرگتر هدر می دهد و بر زمان جستجوی خط مشی زمان اجرا تأثیر منفی می گذارد.

بارگذاری پویا سیاست SELinux

خط مشی SELinux را به صورت پویا در دستگاه های Android بارگیری نکنید. انجام این کار می تواند منجر به مشکلاتی مانند:

• جلوگیری از پذیرش وصله های امنیتی حیاتی.
• افشای توانایی روت کردن دستگاه از طریق بارگذاری مجدد خط مشی ها.
• افشای یک بردار برای حملات انسان در وسط علیه به روز رسانی سیاست.
• به دلیل خطاهای به‌روزرسانی خط‌مشی، دستگاه‌های آجری ایجاد می‌شوند.

درهای پشتی

برنامه‌های اندرویدی نباید هیچ درب پشتی یا راه‌هایی برای دسترسی به سیستم یا داده‌هایی داشته باشند که مکانیسم‌های امنیتی عادی را دور بزنند. این شامل عیب‌یابی، اشکال‌زدایی، توسعه یا تعمیر ضمانت‌نامه دسترسی ویژه است که توسط اسرار شناخته شده برای توسعه‌دهنده بسته شده است. برای جلوگیری از درهای پشتی:

• همه برنامه های شخص ثالث را با استفاده از ابزار اسکن آسیب پذیری برنامه های شناخته شده در صنعت اسکن کنید.
• بررسی کد همه کدهای دارای دسترسی حساس، از جمله کتابخانه های شخص ثالث را انجام دهید.
• با آپلود برنامه‌ها در Google Play برای اسکن، از Google Play Protect استفاده کنید. می‌توانید برنامه‌ها را برای اسکن بدون انتشار در Google Play آپلود کنید.
• ابزارهای عیب‌یابی یا تعمیر را در نسخه‌های منتشر شده از قبل بارگذاری نکنید. این ابزارها را فقط بر حسب تقاضا برای حل مشکلات خاص نصب کنید. به‌علاوه، این ابزارها نباید بر اساس داده‌های خاص حساب کار کنند یا آن را آپلود کنند.

ابزار توسعه

ابزارهای توسعه، مانند ابزارهای اشکال زدایی، آزمایش و تشخیص، اغلب می توانند با آشکار کردن نحوه عملکرد و داده هایی که جمع آوری می کنند، شکاف های امنیتی ناخواسته ای را در دستگاه شما ایجاد کنند. برای اطمینان از اینکه ابزارهای توسعه آن را وارد ساخت‌های تولیدی نمی‌کنند:

• قبل از استفاده از تصویر سیستم، فهرست سیاهی از هش‌های ابزار اشکال‌زدایی و آزمایش داخلی ایجاد کنید و ساخت‌های این APK را اسکن کنید.
• با استفاده از ابزار اسکن آسیب پذیری برنامه های شناخته شده در صنعت، تمام برنامه های شخص اول را اسکن کنید.
• یک شرکت تست امنیت برنامه شخص ثالث را استخدام کنید تا همه برنامه‌های تشخیصی مهم روی دستگاه را قبل از هر به‌روزرسانی مهمی ارزیابی کند، به‌خصوص اگر برنامه توسط شخص ثالثی توسعه داده شده باشد.
• اطمینان حاصل کنید که فقط کاربر می تواند ابزار را به صورت شفاهی یا از طریق چت در طول جلسه پشتیبانی فعال کند. مصنوعات رضایت را ذخیره کنید و پس از جمع آوری اطلاعات تشخیصی لازم، ابزار را غیرفعال کنید.
• سابقه استفاده از این ابزار را در یک گزارش قابل دسترسی توسط کاربر در حساب حامل خود ذخیره کنید.
• اطمینان حاصل کنید که هرگونه اطلاعات شناسایی شخصی (PII) یا داده‌های تله‌متری دستگاه جمع‌آوری‌شده توسط این ابزار مشمول شیوه‌های ناشناس، حفظ و حذف مربوط به کشور است. فقط داده های مربوط به تماس پشتیبانی باید جمع آوری شود. این داده ها باید پس از هر تماس حذف شوند.
• اطمینان حاصل کنید که تکنیک‌هایی که می‌توانند برای نرم‌افزارهای جاسوسی استفاده شوند، مانند ثبت با ضربه زدن به کلید، استفاده از میکروفون، یا استفاده از دوربین، بدون رضایت صریح کاربر استفاده نمی‌شوند. برنامه‌هایی که از این روش‌های بالقوه تهاجمی به حریم خصوصی استفاده می‌کنند باید به‌طور واضح همراه با خط‌مشی رازداری که کاربر باید با آن موافقت کند، افشا شود. برنامه هایی مانند این نباید بدون رضایت صریح کاربر فعال شوند.

در اینجا چند پیشنهاد اضافی وجود دارد که باید هنگام اجرای افشا و رضایت به آنها اشاره کرد:

افشای درون برنامه ای

• استفاده عادی از برنامه را مستقیماً در برنامه نمایش دهید. لازم نیست کاربر به منو یا تنظیمات پیمایش کند.
• نوع داده های جمع آوری شده را شرح دهید و نحوه استفاده از داده ها را توضیح دهید.
• در حالت ایده آل، این اطلاعات را در خط مشی رازداری یا شرایط خدمات جاسازی نکنید. آن را با سایر افشاگری‌های غیر مرتبط با جمع‌آوری داده‌های شخصی یا حساس وارد نکنید.

درخواست رضایت

• رضایت باید مثبت باشد. پیمایش دور از افشا، از جمله دور زدن یا فشار دادن دکمه بازگشت یا صفحه اصلی را به عنوان رضایت تلقی نکنید.
• گفتگوی رضایت را به صورت واضح و بدون ابهام ارائه دهید.
• برای پذیرش، به اقدام مثبت کاربر، مانند ضربه زدن برای پذیرش یا گفتن فرمان، نیاز دارید.
• قبل از کسب رضایت نامه، داده های شخصی یا حساس را جمع آوری نکنید.
• از پیام‌های رد خودکار یا منقضی شده استفاده نکنید.

قابلیت تعبیه شده در AOSP

تعبیه عملکرد اضافی در AOSP اغلب می تواند رفتار و پیامدهای غیرمنتظره ای داشته باشد. با احتیاط ادامه دهید

• اطمینان حاصل کنید که اگر کاربر می‌خواهد از برنامه‌های پیش‌فرض مختلف (مثلاً موتور جستجو، مرورگر وب، راه‌انداز) استفاده کند و داده‌های ارسال شده را از دستگاه فاش کند، از آن خواسته می‌شود.
• اطمینان حاصل کنید که AOSP APK با گواهی AOSP امضا شده است.
• تست‌های رگرسیون را اجرا کنید و یک گزارش تغییرات نگه دارید تا مشخص کنید آیا AOSP APK کد اضافه شده است یا خیر.

به روز رسانی های امنیتی

دستگاه های اندرویدی باید حداقل تا دو سال پس از راه اندازی، پشتیبانی امنیتی مداوم دریافت کنند. این شامل دریافت به‌روزرسانی‌های منظم است که آسیب‌پذیری‌های امنیتی شناخته شده را برطرف می‌کند.

• با شرکای سخت افزاری مانند فروشندگان SoC خود کار کنید تا توافق نامه های پشتیبانی مناسب را برای همه اجزای دستگاه Android خود تنظیم کنید.
• اطمینان حاصل کنید که به‌روزرسانی‌های امنیتی را می‌توان با حداقل تعامل کاربر نصب کرد تا احتمال پذیرش و نصب به‌روزرسانی‌ها در دستگاه اندرویدی توسط کاربران افزایش یابد. اجرای به روزرسانی های سیستم یکپارچه یا یک ویژگی امنیتی معادل آن به شدت توصیه می شود.
• اطمینان حاصل کنید که نیاز تجمعی سطح پچ امنیتی اندرویدی (SPL) را همانطور که در بولتن امنیت اندرویدی اعلام شده است ، درک کرده اید. به عنوان مثال ، دستگاه هایی که از سطح پچ امنیتی 2018-02-01 استفاده می کنند ، باید شامل کلیه موارد مرتبط با آن سطح پچ امنیتی و همچنین رفع کلیه موارد گزارش شده در کلیه بولتن های امنیتی قبلی باشند.

به روزرسانی های هسته پویا

به صورت پویا اجزای سیستم بحرانی را تغییر ندهید. در حالی که برخی تحقیقات وجود دارد که نشان می دهد به روزرسانی های پویا هسته به محافظت در برابر تهدیدهای اضطراری کمک می کند ، هزینه ارزیابی شده در حال حاضر از مزایا بیشتر است. در عوض ، برای توزیع سریع محافظت از آسیب پذیری ، یک روش به روزرسانی قوی OTA ایجاد کنید.

مدیریت کلید

سیاست ها و شیوه های مدیریت کلیدی خوب را برای اطمینان از امنیت کلیدهای امضای حفظ کنید.

• کلیدهای امضای را با مهمانی های خارجی به اشتراک نگذارید.
• اگر یک کلید امضاء به خطر افتاده است ، یک کلید جدید تولید کنید و تمام برنامه ها را که به جلو می روند ، امضا کنید.
• تمام کلیدها را در سخت افزار یا خدمات ماژول با امنیت بالا ذخیره کنید که به چندین عامل برای دسترسی نیاز دارند.

امضای تصویر سیستم

امضای تصویر سیستم برای تعیین یکپارچگی دستگاه بسیار مهم است.

• دستگاه ها را با یک کلید شناخته شده عمومی امضا نکنید.
• مدیریت کلیدهای امضای دستگاه به روشی مطابق با شیوه های استاندارد صنعت برای رسیدگی به کلیدهای حساس ، از جمله ماژول امنیتی سخت افزار (HSM) که دسترسی محدود و قابل شنیدن را فراهم می کند.

bootloaders قابل باز کردن

بسیاری از دستگاه های Android از باز کردن قفل پشتیبانی می کنند ، و صاحب دستگاه را قادر می سازد تا پارتیشن سیستم را تغییر دهد یا یک سیستم عامل سفارشی نصب کند. موارد استفاده متداول شامل نصب تصویر سیستم شخص ثالث و انجام توسعه سطح سیستم در دستگاه است. به عنوان مثال ، برای باز کردن تصویر سیستم در Google Nexus یا Pixel ، یک کاربر می تواند fastboot oem unlock اجرا کند ، که این پیام را نشان می دهد:

به عنوان بهترین روش ، دستگاه های Android غیرقابل باز کردن باید قبل از قفل قفل ، تمام داده های کاربر را پاک کنند. عدم حذف صحیح تمام داده ها در مورد باز کردن قفل ممکن است به یک مهاجم نزدیک جسمی اجازه دهد تا دسترسی غیرمجاز به داده های کاربر محرمانه اندرویدی را بدست آورد. برای جلوگیری از افشای داده های کاربر ، دستگاهی که از باز کردن قفل پشتیبانی می کند باید آن را به درستی پیاده سازی کند.

• بعد از اینکه کاربر دستور باز کردن قفل را تأیید کرد ، دستگاه باید یک فوری داده را پاک کند. پرچم unlocked تا پس از اتمام حذف ایمن ، نباید تنظیم شود.
• اگر حذف ایمن به پایان نرسد ، دستگاه باید در حالت قفل شده بماند.
• در صورت پشتیبانی توسط دستگاه بلوک زیرین ، باید از ioctl(BLKSECDISCARD) یا معادل آن استفاده شود. برای دستگاه های تعبیه شده Multimediacard (EMMC) ، این به معنای استفاده از یک فرمان پاک یا پاک کننده ایمن است. برای EMMC 4.5 و بعد از آن ، این به معنای استفاده از پاک کردن یا تریم طبیعی است که به دنبال آن یک عمل ضد عفونی است.
• اگر BLKSECDISCARD توسط دستگاه بلوک زیرین پشتیبانی نمی شود ، به جای آن باید از ioctl(BLKDISCARD) استفاده شود. در دستگاه های EMMC ، این یک عمل تر و تمیز طبیعی است.
• اگر BLKDISCARD پشتیبانی نشود ، بازنویسی دستگاه های بلوک با تمام صفرها قابل قبول است.
• کاربر باید این گزینه را داشته باشد که قبل از چشمک زدن به یک پارتیشن ، داده های کاربر را پاک کند. به عنوان مثال ، دستگاه های Nexus برای پاک کردن داده های کاربر از دستور fastboot oem lock استفاده می کنند.
• یک دستگاه ممکن است از طریق EFUSES یا مکانیسم مشابه ضبط کند ، خواه یک دستگاه قفل شود و یا مجدداً مجدداً مورد استفاده قرار گیرد. با این حال ، ما اکیداً توصیه می کنیم که مجدداً با استفاده از تنظیم مجدد کارخانه ، عملکرد کامل دستگاه را بازیابی کنید.

این الزامات اطمینان حاصل می کند که تمام داده ها پس از اتمام عمل قفل از بین می روند. عدم اجرای این حمایت ها یک آسیب پذیری امنیتی سطح متوسط ​​محسوب می شود.

دستگاهی که باز نشده باشد ممکن است متعاقباً با استفاده از دستور fastboot oem lock دوباره مجدداً مورد استفاده قرار گیرد. قفل کردن bootloader همان محافظت از داده های کاربر را با سیستم عامل سفارشی جدید فراهم می کند ، همانطور که با سیستم عامل اصلی سازنده دستگاه در دسترس بود (به عنوان مثال ، در صورت قفل شدن دستگاه ، داده های کاربر از بین می رود).

پنتیکار دستگاه

دستگاه ها باید قبل از حمل و نقل توسط یک پنتستر صالح بررسی شوند. پنتس کردن باید ثابت کند که دستگاه از راهنمایی های امنیتی ارائه شده در اینجا و همچنین راهنمایی های امنیتی داخلی OEM پیروی می کند.

تست امنیتی

از ابزارهای تست امنیتی ارائه شده توسط AOSP استفاده کنید. به طور خاص

• در حین توسعه از ابزارهای ایمنی حافظه استفاده کنید: از MTE در جایی که پشتیبانی می شود (ARMV9 و بالاتر) و Hwasan در جایی که نیست استفاده کنید. تا حد امکان تست ها را با این ابزارها فعال کنید.
• برای تشخیص احتمالی مسائل ایمنی حافظه ، از GWP-Asan و Kfence در تولید استفاده کنید.