ماژول رمزنگاری GKI قابل تایید FIPS 140-3

هسته GKI شامل یک ماژول هسته لینوکس به نام 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 خارج نمی‌شوند، بلکه در ماژول کپی می‌شوند. هنگامی که ماژول بارگذاری می‌شود، روتین‌های رمزنگاری داخلی از CryptoAPI لینوکس حذف شده و توسط روتین‌های حمل شده توسط ماژول جایگزین می‌شوند.

این بدان معناست که ماژول fips140.ko کاملاً اختیاری است و فقط در صورتی که گواهینامه FIPS 140-3 الزامی باشد، استفاده از آن منطقی است. فراتر از آن، این ماژول هیچ قابلیت اضافی ارائه نمی‌دهد و بارگذاری غیرضروری آن فقط احتمالاً بر زمان بوت تأثیر می‌گذارد، بدون اینکه هیچ فایده‌ای داشته باشد.

نحوه استقرار ماژول

این ماژول را می‌توان با استفاده از مراحل زیر در ساخت اندروید گنجاند:

  • نام ماژول را به BOARD_VENDOR_RAMDISK_KERNEL_MODULES اضافه کنید. این باعث می‌شود که ماژول در ramdisk فروشنده کپی شود.
  • نام ماژول را به BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD اضافه کنید. این باعث می‌شود نام ماژول به modules.load در مقصد اضافه شود. modules.load لیست ماژول‌هایی را که هنگام بوت شدن دستگاه توسط init بارگذاری می‌شوند، در خود نگه می‌دارد.

خودآزمایی یکپارچگی

ماژول هسته FIPS 140-3 خلاصه HMAC-SHA256 بخش‌های .code و .rodata خود را در زمان بارگذاری ماژول دریافت می‌کند و آن را با خلاصه ثبت‌شده در ماژول مقایسه می‌کند. این کار پس از آن انجام می‌شود که لودر ماژول لینوکس اصلاحات معمول مانند پردازش جابجایی ELF و وصله‌های جایگزین برای خطاهای CPU را در آن بخش‌ها انجام داده باشد. مراحل اضافی زیر برای اطمینان از بازتولید صحیح خلاصه انجام می‌شود:

  • جابجایی‌های ELF در داخل ماژول حفظ می‌شوند تا بتوان آنها را به صورت معکوس به ورودی HMAC اعمال کرد.
  • این ماژول هرگونه وصله کدی را که توسط هسته برای Dynamic Shadow Call Stack ساخته شده است، معکوس می‌کند. به طور خاص، این ماژول هر دستورالعملی را که از Shadow Call Stack حذف یا اضافه می‌شود، با دستورالعمل‌های Pointer Authentication Code (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 . در CPUهایی با افزونه‌های رمزنگاری 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( ) تشکیل داد. cmac( ) . پیاده‌سازی‌های دیگر مستقل هستند.
ecb(aes) ecb (الگو)، ecb-aes-neon ، ecb-aes-neonbs ، ecb-aes-ce بله AES-ECB: تمام اندازه‌های کلید AES پشتیبانی می‌شوند. الگوی ecb را می‌توان با هر پیاده‌سازی aes با استفاده از ecb( ) ترکیب کرد. ecb( ) . پیاده‌سازی‌های دیگر مستقل هستند.
cbc(aes) cbc (الگو)، cbc-aes-neon ، cbc-aes-neonbs ، cbc-aes-ce بله AES-CBC: تمام اندازه‌های کلید AES پشتیبانی می‌شوند. الگوی cbc را می‌توان با هر پیاده‌سازی aes با استفاده از cbc( ) تشکیل داد. cbc( ) . پیاده‌سازی‌های دیگر مستقل هستند.
cts(cbc(aes)) cts (الگو)، cts-cbc-aes-neon ، cts-cbc-aes-ce بله AES-CBC-CTS یا AES-CBC با سرقت متن رمزی: قرارداد مورد استفاده CS3 است؛ دو بلوک متن رمزی نهایی بدون قید و شرط تعویض می‌شوند. تمام اندازه‌های کلید AES پشتیبانی می‌شوند. الگوی cts را می‌توان با هر پیاده‌سازی cbc با استفاده از cts( ) تشکیل داد. cts( ) . پیاده‌سازی‌های دیگر مستقل هستند.
ctr(aes) ctr (الگو)، ctr-aes-neon ، ctr-aes-neonbs ، ctr-aes-ce بله AES-CTR: تمام اندازه‌های کلید AES پشتیبانی می‌شوند. الگوی ctr را می‌توان با هر پیاده‌سازی aes با استفاده از ctr( ) تشکیل داد. ctr( ) . پیاده‌سازی‌های دیگر مستقل هستند.
xts(aes) xts (قالب)، xts-aes-neon ، xts-aes-neonbs ، xts-aes-ce بله AES-XTS: در هسته ۶.۱ و پایین‌تر، تمام اندازه‌های کلید AES پشتیبانی می‌شوند؛ در هسته ۶.۶ و بالاتر، فقط AES-128 و AES-256 پشتیبانی می‌شوند. الگوی xts را می‌توان با هر پیاده‌سازی ecb(aes) با استفاده از xts( ) ترکیب کرد. xts( ) . پیاده‌سازی‌های دیگر مستقل هستند. همه پیاده‌سازی‌ها بررسی کلید ضعیف مورد نیاز FIPS را پیاده‌سازی می‌کنند؛ یعنی کلیدهای XTS که نیمه اول و دوم آنها برابر است، رد می‌شوند.
gcm(aes) gcm (الگو)، gcm-aes-ce شماره ۱ AES-GCM: تمام اندازه‌های کلید AES پشتیبانی می‌شوند. فقط IV های ۹۶ بیتی پشتیبانی می‌شوند. همانند سایر حالت‌های AES در این ماژول، فراخوانی‌کننده مسئول ارائه IV ها است. الگوی gcm را می‌توان با هر پیاده‌سازی ctr(aes) و ghash با استفاده از gcm_base( , ) ترکیب کرد. gcm_base( , ) . پیاده‌سازی‌های دیگر مستقل هستند.
sha1 کرنل ۶.۱۲ و پایین‌تر: sha1-generic ، sha1-ce بله تابع هش رمزنگاری SHA-1. در هسته ۶.۱۸ و بالاتر حذف شده است.
sha224 کرنل ۶.۱۸ و بالاتر: sha224-lib . کرنل ۶.۱۲ و پایین‌تر: sha224-generic ، sha224-arm64 ، sha224-ce بله تابع هش رمزنگاری SHA-224: این کد با SHA-256 به اشتراک گذاشته شده است.
sha256 هسته ۶.۱۸ و بالاتر: sha256-lib . هسته ۶.۱۲ و پایین‌تر: sha256-generic ، sha256-arm64 ، sha256-ce ، کتابخانه SHA-256 بله تابع هش رمزنگاری SHA-256.
sha384 کرنل ۶.۱۸ و بالاتر: sha384-lib . کرنل ۶.۱۲ و پایین‌تر: sha384-generic ، sha384-arm64 ، sha384-ce بله تابع هش رمزنگاری SHA-384: این کد با SHA-512 به اشتراک گذاشته شده است.
sha512 کرنل ۶.۱۸ و بالاتر: 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( ) یا hmac( ) .
stdrng همه کرنل‌ها: drbg_pr_hmac_sha256 ، drbg_pr_hmac_sha384 ، drbg_pr_hmac_sha512 . کرنل ۶.۶ و پایین‌تر: 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 مخصوص به خود را دریافت می‌کنند. آن‌ها از نمونه‌هایی که DRBGها استفاده می‌کنند، دوباره استفاده نمی‌کنند.
xcbc(aes) xcbc-aes-neon ، xcbc-aes-ce خیر
xctr(aes) هسته ۵.۱۵ و بالاتر: 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 ماژول می‌توانند از نظر الگوریتم تأیید شوند اما از نظر ماژول تأیید نمی‌شوند. آن‌ها می‌توانند اعتبارسنجی شوند، اما AES-GCM را نمی‌توان از دیدگاه ماژول FIPS یک الگوریتم تأیید شده در نظر گرفت. دلیل این امر آن است که الزامات ماژول FIPS برای GCM با پیاده‌سازی‌های GCM که IVهای خود را تولید نمی‌کنند، سازگار نیست.

ساخت ماژول از منبع

برای اندروید ۱۴ و بالاتر (از جمله 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 تعبیه شده در آن انجام می‌دهند.

راهنمایی کاربر نهایی

راهنمایی افسر رمزنگاری

برای کار با ماژول هسته، سیستم عامل باید به یک حالت عملیاتی واحد محدود شود. این کار به طور خودکار توسط اندروید با استفاده از سخت‌افزار مدیریت حافظه در پردازنده انجام می‌شود.

ماژول هسته را نمی‌توان جداگانه نصب کرد؛ این ماژول به عنوان بخشی از میان‌افزار دستگاه گنجانده شده و به طور خودکار هنگام بوت بارگذاری می‌شود. این ماژول فقط در یک حالت عملیاتی تأیید شده عمل می‌کند.

مسئول رمزنگاری می‌تواند با راه‌اندازی مجدد دستگاه، در هر زمانی باعث اجرای خودآزمایی‌ها شود.

راهنمایی کاربر

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

استفاده از الگوریتم‌ها برای اهداف انطباق با FIPS محدود به الگوریتم‌های تأیید شده است. برای برآورده کردن الزام "شاخص سرویس" FIPS 140-3، این ماژول تابعی به نام fips140_is_approved_service ارائه می‌دهد که نشان می‌دهد آیا یک الگوریتم تأیید شده است یا خیر.

خطاهای خودآزمایی

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