هسته GKI شامل واحد هسته Linux به‌نام fips140.ko است که
با الزامات FIPS 140-3 برای واحدهای نرم‌افزاری رمزنگاری مطابقت دارد.
اگر محصولی که هسته GKI را اجرا می‌کند به این گواهینامه نیاز داشته باشد، می‌توان این واحد را برای گواهینامه FIPS ارسال کرد.
به‌طور خاص، الزامات زیر از FIPS 140-3 باید قبل‌از استفاده از روال‌های رمزنگاری برآورده شوند:
- واحد باید پیش‌از دردسترس قرار دادن الگوریتم‌های رمزنگاری، یکپارچگی خود را بررسی کند.
- واحد باید پیش‌از دردسترس قرار دادن الگوریتم‌های رمزنگاری تأییدشده خود، آن‌ها را بااستفاده از خودآزمایی‌های الگوریتم رمزنگاری اجرا و درستی‌سنجی کند.
چرا واحد هسته جداگانه
اعتبارسنجی FIPS 140-3 براساس این ایده است که وقتی یک ماژول مبتنی بر نرم‌افزار یا سخت‌افزار گواهی دریافت می‌کند، هرگز تغییر نمی‌کند. اگر تغییر کرد، باید دوباره گواهی شود. این امر به‌راحتی با فرایندهای توسعه نرم‌افزار در استفاده امروزی مطابقت ندارد، و در نتیجه این الزام، واحدهای نرم‌افزار FIPS عموماً به‌گونه‌ای طراحی می‌شوند که تا حد امکان بر اجزای رمزنگاری متمرکز باشند، تا اطمینان حاصل شود که تغییراتی که مربوط به رمزنگاری نیستند نیاز به ارزیابی مجدد رمزنگاری ندارند.
هسته GKI درطول کل عمر پشتیبانی‌شده خود به‌طور منظم به‌روزرسانی می‌شود. این امر باعث می‌شود که کل هسته در محدوده واحد FIPS قرار نگیرد، زیرا چنین واحدی باید پس‌از هر به‌روزرسانی هسته مجدداً گواهی شود. تعریف «واحد FIPS» به‌عنوان زیرمجموعه‌ای از تصویر هسته این مشکل را کاهش می‌دهد اما آن را حل نمی‌کند، زیرا محتوای باینری «واحد FIPS» همچنان بسیار بیشتر از حد نیاز تغییر می‌کند.
قبل‌از نسخه ۶.۱ هسته، نکته مهم دیگر این بود که GKI با LTO (بهینه‌سازی زمان پیوند) فعال کامپایل می‌شد، زیرا LTO پیش‌نیاز تمامیت جریان کنترل بود که ویژگی امنیتی مهمی است.
بنابراین، همه کدهایی که تحت پوشش الزامات FIPS 140-3 هستند در یک واحد هسته جداگانه fips140.ko بسته‌بندی می‌شوند که فقط به میاناهای پایدار آشکارشده توسط منبع هسته GKI که از آن ساخته شده است متکی است. این
یعنی پیمانه می‌تواند با نسخه‌های مختلف GKI از یک نسل استفاده شود، و
فقط درصورتی باید برای دریافت گواهینامه به‌روزرسانی و دوباره ارسال شود که
مشکلی در کدی که خود پیمانه حمل می‌کند برطرف شده باشد.
زمان استفاده از واحد
هسته GKI خود حاوی کدی است که به روال‌های رمزنگاری که در واحد هسته FIPS 140-3 نیز بسته‌بندی شده‌اند وابسته است. بنابراین، روال‌های رمزنگاری داخلی درواقع از هسته GKI خارج نمی‌شوند، بلکه در واحد کپی می‌شوند. وقتی واحد بار می‌شود، روال‌های رمزنگاری داخلی از «میانای برنامه‌سازی کاربردی رمزنگاری Linux» لغو ثبت می‌شوند و با روال‌های موجود در واحد جایگزین می‌شوند.
این یعنی واحد fips140.ko کاملاً اختیاری است و فقط درصورتی استقرار آن منطقی است که گواهینامه FIPS 140-3 الزامی باشد. علاوه‌براین،
این واحد هیچ قابلیت اضافه‌ای ارائه نمی‌دهد و بار کردن غیرضروری آن
فقط احتمالاً بر زمان راه‌اندازی تأثیر می‌گذارد و هیچ سودی ندارد.
نحوه استقرار واحد
بااستفاده از مراحل زیر می‌توان واحد را در ساخت Android گنجاند:
- نام واحد را به
BOARD_VENDOR_RAMDISK_KERNEL_MODULESاضافه کنید. این کار باعث می‌شود واحد به ramdisk فروشنده کپی شود. - نام واحد را به
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOADاضافه کنید. این کار باعث می‌شود نام واحد بهmodules.loadدر هدف اضافه شود. modules.loadفهرست واحدهایی را کهinitهنگام راه‌اندازی دستگاه بار می‌کند دربرمی‌گیرد.
بررسی تمامیت خودکار
واحد هسته FIPS 140-3 در زمان بار کردن واحد، خلاصه HMAC-SHA256 بخش‌های .code
و .rodata خود را می‌گیرد و آن را با خلاصه
ضبط‌شده در واحد مقایسه می‌کند. این کار پس‌از آن انجام می‌شود که بارکننده واحد Linux
قبلاً تغییرات معمول را مانند پردازش جابه‌جایی ELF و
وصله کردن جایگزین‌ها برای خطاهای CPU در آن بخش‌ها انجام داده باشد. مراحل تکمیلی زیر برای اطمینان از اینکه خلاصه می‌تواند به‌درستی بازتولید شود، انجام می‌شود:
- جابه‌جایی‌های ELF در داخل ماژول حفظ می‌شوند تا بتوان آن‌ها را به‌صورت معکوس در ورودی HMAC اعمال کرد.
- واحد هر وصله کدی را که هسته برای «پشته تماس سایه پویا» ایجاد کرده است برمی‌گرداند. به‌طور خاص، این ماژول هر دستورالعملی را که از پشته فراخوانی سایه push یا pop می‌کند با دستورالعمل‌های «کد اصالت‌سنجی اشاره‌گر» (PAC) که در ابتدا وجود داشتند جایگزین می‌کند.
- همه وصله‌های کد دیگر برای این ماژول غیرفعال است، ازجمله کلیدهای ثابت و بنابراین نقاط ردیابی و همچنین قلاب‌های فروشنده.
خودآزمایی الگوریتم رمزنگاری
واحد هسته FIPS 140-3 با پیاده‌سازی آزمایش‌های پاسخ شناخته‌شده، الزامات خودآزمایی الگوریتم رمزنگاری FIPS 140-3 را برآورده می‌کند. آزمایش‌های پیاده‌سازی‌شده براساس الگوریتم متفاوت است و از دستورالعمل پیاده‌سازی FIPS 140-3 10.3.A پیروی می‌کند.
به‌طور کلی، فقط یک بردار آزمایشی برای هر الگوریتم لازم است. خودآزمایی‌های الگوریتم رمزنگاری FIPS فقط برای اعتبارسنجی عملکرد پایه طراحی شده است. آزمایش جامع به‌صورت جداگانه بااستفاده از «برنامه تأیید الگوریتم رمزنگاری» (CAVP) و مجموعه آزمایش رمزنگاری هسته بالادستی انجام می‌شود.
وقتی الگوریتمی چندین پیاده‌سازی دارد که کاربر می‌تواند به آن‌ها دسترسی داشته باشد یا سرویس‌های واحد از آن‌ها استفاده می‌کند،
طبق الزامات FIPS 140-3، همه آن پیاده‌سازی‌ها باید خودآزمایی شوند. این موضوع با استراتژی یکپارچه‌سازی که به‌طور سنتی توسط Linux CryptoAPI استفاده می‌شود مرتبط است، جایی که هر الگوریتم می‌تواند چندین پیاده‌سازی قابل‌دسترس برای کاربر داشته باشد. برای مثال، در هسته android16-6.12، SHA-256 سه پیاده‌سازی دارد: sha256-generic، sha256-arm64، و sha256-ce. در واحدهای پردازش مرکزی با افزونه‌های رمزنگاری ARMv8، به‌طور پیش‌فرض از sha256-ce استفاده می‌شود، اما کاربران همچنان می‌توانند به‌طور صریح به موارد دیگر دسترسی داشته باشند. بنابراین، پیمانه هر سه پیاده‌سازی را خودآزمایی می‌کند.
در هسته android17-6.18 و بالاتر، برخی‌از الگوریتم‌ها از استراتژی
ادغام ساده‌تری استفاده می‌کنند. برای مثال، در هسته android17-6.18، SHA-256 یک
پیاده‌سازی واحد sha256-lib دارد که به‌طور خودکار کد مناسب
را برای CPU در زمان بار کردن ماژول انتخاب می‌کند. بنابراین، این ماژول فقط خودآزمایی می‌کند
sha256-lib.
الگوریتم‌های موجود در واحد
همه الگوریتم‌هایی که در واحد FIPS 140-3 گنجانده شده‌اند به شرح زیر فهرست شده‌اند.
این موضوع برای شاخه‌های هسته android12-5.10، android13-5.10، android13-5.15،
android14-5.15، android14-6.1، android15-6.6، android16-6.12، و
android17-6.18 اعمال می‌شود، هرچند درصورت لزوم تفاوت‌های بین نسخه‌های هسته ذکر می‌شود.
| الگوریتم | پیاده‌سازی‌ها | قابل‌تأیید | تعریف |
|---|---|---|---|
aes |
aes-generic، aes-arm64، aes-ce، کتابخانه AES |
بله | رمز بلوک AES ساده، بدون حالت عملیاتی: همه اندازه‌های کلید (۱۲۸ بیت، ۱۹۲ بیت، و ۲۵۶ بیت) پشتیبانی می‌شوند. همه پیاده‌سازی‌ها به‌جز پیاده‌سازی کتابخانه را می‌توان با حالت عملیاتی ازطریق الگو ترکیب کرد. |
cmac(aes) |
cmac (الگو)، cmac-aes-neon، cmac-aes-ce |
بله | AES-CMAC: همه اندازه‌های کلید AES پشتیبانی می‌شود. الگوی cmac را می‌توان با هر پیاده‌سازی aes بااستفاده از cmac( ساخت. پیاده‌سازی‌های دیگر مستقل هستند. |
ecb(aes) |
ecb (الگو)، ecb-aes-neon، ecb-aes-neonbs، ecb-aes-ce |
بله | AES-ECB: از همه اندازه‌های کلید AES پشتیبانی می‌شود. الگوی ecb را می‌توان با هر پیاده‌سازی aes بااستفاده از ecb( ساخت. پیاده‌سازی‌های دیگر مستقل هستند. |
cbc(aes) |
cbc (الگو)، cbc-aes-neon، cbc-aes-neonbs، cbc-aes-ce |
بله | AES-CBC: همه اندازه‌های کلید AES پشتیبانی می‌شود. الگوی cbc را می‌توان با هر پیاده‌سازی aes بااستفاده از cbc( ترکیب کرد. پیاده‌سازی‌های دیگر مستقل هستند. |
cts(cbc(aes)) |
cts (الگو)، cts-cbc-aes-neon، cts-cbc-aes-ce |
بله | AES-CBC-CTS یا AES-CBC با سرقت متن رمزی: قرارداد استفاده‌شده CS3 است؛ دو بلوک متن رمزی نهایی بدون قیدوشرط جابه‌جا می‌شوند. همه اندازه‌های کلید AES پشتیبانی می‌شوند. الگوی cts را می‌توان با هر پیاده‌سازی cbc بااستفاده از cts( ساخت. پیاده‌سازی‌های دیگر مستقل هستند. |
ctr(aes) |
ctr (الگو)، ctr-aes-neon، ctr-aes-neonbs، ctr-aes-ce |
بله | AES-CTR: از همه اندازه‌های کلید AES پشتیبانی می‌شود. الگوی ctr را می‌توان با هر پیاده‌سازی aes بااستفاده از ctr( ترکیب کرد. پیاده‌سازی‌های دیگر مستقل هستند. |
xts(aes) |
xts (الگو)، xts-aes-neon، xts-aes-neonbs، xts-aes-ce |
بله | AES-XTS: در هسته ۶.۱ و پایین‌تر، از همه اندازه‌های کلید AES پشتیبانی می‌شود؛ در هسته ۶.۶ و بالاتر، فقط از AES-128 و AES-256 پشتیبانی می‌شود. الگوی xts را می‌توان با هر پیاده‌سازی ecb(aes) بااستفاده از xts( ساخت. پیاده‌سازی‌های دیگر مستقل هستند. همه پیاده‌سازی‌ها بررسی کلید ضعیف موردنیاز FIPS را پیاده‌سازی می‌کنند؛ یعنی کلیدهای XTS که نیمه اول و دوم آن‌ها برابر است رد می‌شوند. |
gcm(aes) |
gcm (الگو)، gcm-aes-ce |
نه ۱ | AES-GCM: از همه اندازه‌های کلید AES پشتیبانی می‌شود. فقط از IVهای ۹۶ بیتی پشتیبانی می‌شود. مانند همه حالت‌های دیگر AES در این واحد، تماس‌گیرنده مسئول ارائه IV است. الگوی gcm را می‌توان با هر پیاده‌سازی از ctr(aes) و ghash بااستفاده از gcm_base( ترکیب کرد. پیاده‌سازی‌های دیگر مستقل هستند. |
sha1 |
Kernel 6.12 و نسخه‌های پایین‌تر: sha1-generic، sha1-ce |
بله | تابع درهم‌ساز رمزنگاری SHA-1. در هسته ۶.۱۸ و بالاتر برداشته شده است. |
sha224 |
Kernel 6.18 و بالاتر: sha224-lib. Kernel 6.12 و نسخه‌های پایین‌تر: sha224-generic، sha224-arm64، sha224-ce |
بله | تابع درهم‌سازی رمزنگاری SHA-224: کد با SHA-256 هم‌رسانی می‌شود. |
sha256 |
Kernel 6.18 و بالاتر: sha256-lib. Kernel 6.12 و پایین‌تر: sha256-generic، sha256-arm64، sha256-ce، کتابخانه SHA-256 |
بله | تابع درهم‌ساز رمزنگاری SHA-256. |
sha384 |
Kernel نسخه ۶.۱۸ و بالاتر: sha384-lib. هسته ۶.۱۲ و پایین‌تر: sha384-generic، sha384-arm64، sha384-ce |
بله | تابع درهم‌سازی رمزنگاری SHA-384: کد با SHA-512 هم‌رسانی می‌شود. |
sha512 |
Kernel 6.18 و بالاتر: sha512-lib. هسته ۶.۱۲ و پایین‌تر: sha512-generic، sha512-arm64، sha512-ce |
بله | تابع درهم‌ساز رمزنگاری SHA-512. |
sha3-224 |
هسته ۶.۶ و بالاتر: sha3-224-generic |
بله | تابع درهم‌ساز رمزنگاری SHA3-224. |
sha3-256 |
هسته ۶.۶ و بالاتر: sha3-256-generic |
بله | مشابه قبلی، اما با طول خلاصه ۲۵۶ بیتی (SHA3-256). همه طول‌های خلاصه از پیاده‌سازی Keccak یکسانی استفاده می‌کنند. |
sha3-384 |
هسته ۶.۶ و بالاتر: sha3-384-generic |
بله | مشابه قبلی، اما با طول خلاصه ۳۸۴ بیتی (SHA3-384). همه طول‌های خلاصه از پیاده‌سازی Keccak یکسانی استفاده می‌کنند. |
sha3-512 |
هسته ۶.۶ و بالاتر: sha3-512-generic |
بله | مشابه مورد قبلی، اما با طول خلاصه ۵۱۲ بیتی (SHA3-512). همه طول‌های خلاصه از پیاده‌سازی یکسانی از Keccak استفاده می‌کنند. |
hmac |
hmac (الگو) |
بله | کد اصالت‌سنجی پیام درهم‌سازی‌شده (HMAC): الگوی hmac را می‌توان با هر الگوریتم یا پیاده‌سازی SHA بااستفاده از hmac( یا hmac( ساخت. |
stdrng |
همه هسته‌ها: drbg_pr_hmac_sha256، drbg_pr_hmac_sha384، drbg_pr_hmac_sha512. Kernel نسخه ۶.۶ و پایین‌تر: drbg_pr_hmac_sha1 |
بله | HMAC_DRBG با تابع درهم‌سازی نام‌گذاری‌شده و با مقاومت دربرابر پیش‌بینی فعال نمونه‌سازی شد: بررسی‌های سلامت اضافه شده است. کاربران این میانجی نمونه‌های DRBG خودشان را دریافت می‌کنند. |
stdrng |
همه هسته‌ها: drbg_nopr_hmac_sha256، drbg_nopr_hmac_sha384، drbg_nopr_hmac_sha512. هسته ۶.۶ و پایین‌تر: drbg_nopr_hmac_sha1 |
بله | همانند الگوریتم‌های drbg_pr_*، اما با مقاومت پیش‌بینی غیرفعال‌شده. کد با گونه مقاوم دربرابر پیش‌بینی هم‌رسانی می‌شود. در هسته ۵.۱۰، بالاترین اولویت DRBG drbg_nopr_hmac_sha256 است. در هسته ۵.۱۵ و بالاتر، drbg_pr_hmac_sha512 است. |
jitterentropy_rng |
jitterentropy_rng |
نه | Jitter RNG، نسخه ۲.۲.۰ (نسخه هسته ۶.۱ و پایین‌تر) یا نسخه ۳.۴.۰ (نسخه هسته ۶.۶ و بالاتر). کاربران این میانجی نمونه‌های Jitter RNG خودشان را دریافت می‌کنند. آن‌ها از نمونه‌هایی که «گروه‌های هدف پاسخ مستقیم» استفاده می‌کنند استفاده مجدد نمی‌کنند. |
xcbc(aes) |
xcbc-aes-neon، xcbc-aes-ce |
نه | |
xctr(aes) |
Kernel 5.15 و بالاتر: xctr-aes-neon، xctr-aes-ce |
نه | |
cbcmac(aes) |
cbcmac-aes-neon، cbcmac-aes-ce |
نه | |
essiv(cbc(aes),sha256) |
essiv-cbc-aes-sha256-neon، essiv-cbc-aes-sha256-ce |
نه |
۱. پیاده‌سازی‌های AES-GCM واحد می‌تواند موردتأیید الگوریتم باشد اما موردتأیید واحد نباشد. می‌توان آن‌ها را اعتبارسنجی کرد، اما از دیدگاه واحد FIPS، نمی‌توان AES-GCM را الگوریتم تأییدشده درنظر گرفت. این به‌دلیل این است که الزامات واحد FIPS برای GCM با پیاده‌سازی‌های GCM که مقادیر اولیه خود را تولید نمی‌کنند ناسازگار است.
ساختن واحد از منبع
برای Android 14 و بالاتر (ازجمله
android-mainline)، واحد fips140.ko را بااستفاده از دستورات زیر از منبع بسازید.
ساختن با Bazel:
tools/bazel run //common:fips140_distساختن با
build.sh(قدیمی):BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh
این دستورات ساخت کامل شامل هسته و fips140.ko
واحد با محتوای خلاصه HMAC-SHA256 جاسازی‌شده در آن را انجام می‌دهند.
راهنمای کاربر نهایی
راهنمایی «افسر رمزارز»
برای کار کردن با واحد هسته، سیستم‌عامل باید به حالت عملکرد اپراتور واحد محدود شود. این کار به‌طور خودکار توسط Android بااستفاده از سخت‌افزار مدیریت حافظه در پردازنده انجام می‌شود.
واحد هسته را نمی‌توان به‌طور جداگانه نصب کرد؛ این واحد به‌عنوان بخشی از سخت‌افزار دستگاه گنجانده شده است و هنگام راه‌اندازی به‌طور خودکار بار می‌شود. فقط در حالت عملیاتی تأییدشده کار می‌کند.
«مسئول رمزنگاری» می‌تواند با بازراه‌اندازی دستگاه، خودآزمایی‌ها را در هر زمانی اجرا کند.
راهنمای کاربر
کاربر واحد هسته سایر اجزای هسته هستند که باید از الگوریتم‌های رمزنگاری استفاده کنند. واحد هسته منطق اضافی در استفاده از الگوریتم‌ها ارائه نمی‌دهد و هیچ پارامتری را فراتر از زمان موردنیاز برای انجام عملیات رمزنگاری ذخیره نمی‌کند.
استفاده از الگوریتم‌ها برای اهداف مطابقت با FIPS به الگوریتم‌های تأییدشده محدود می‌شود. برای برآورده کردن الزامات «نشانگر خدمات» FIPS 140-3، واحد
عملکردی fips140_is_approved_service ارائه می‌دهد که نشان می‌دهد آیا
الگوریتمی تأیید شده است یا نه.
خطاهای خودآزمایی
درصورت عدم موفقیت در خودآزمایی، واحد هسته باعث می‌شود هسته با مشکل مواجه شود و دستگاه بوت نشود. اگر بازراه‌اندازی دستگاه مشکل را رفع نکرد، دستگاه باید در حالت بازیابی راه‌اندازی شود تا با دوباره فلش کردن دستگاه، مشکل برطرف شود.