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

هسته GKI شامل یک ماژول هسته لینوکس به نام fips140.ko است که با الزامات FIPS 140-3 برای ماژول های نرم افزار رمزنگاری مطابقت دارد. اگر محصولی که هسته GKI را اجرا می کند، این ماژول را می توان برای گواهی FIPS ارسال کرد.

الزامات FIPS 140-3 زیر باید قبل از استفاده از روال های رمزنگاری انجام شود:

  • ماژول باید یکپارچگی خود را قبل از در دسترس قرار دادن الگوریتم های رمزنگاری بررسی کند.
  • ماژول باید قبل از در دسترس قرار دادن الگوریتم های رمزنگاری تایید شده خود با استفاده از خودآزمایی های با پاسخ شناخته شده، تمرین و تأیید کند.

چرا ماژول کرنل جداگانه

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

هسته GKI قرار است به طور منظم در طول عمر پشتیبانی شده خود به روز شود. این امر باعث می شود که کل هسته در محدوده ماژول FIPS غیرممکن باشد، زیرا چنین ماژولی باید پس از هر به روز رسانی هسته مجدداً تأیید شود. تعریف "ماژول FIPS" به عنوان زیرمجموعه ای از تصویر هسته، این مشکل را کاهش می دهد، اما آن را حل نمی کند، زیرا محتویات باینری "ماژول FIPS" همچنان بسیار بیشتر از نیاز تغییر می کند.

قبل از نسخه 6.1 هسته، یکی دیگر از ملاحظات این بود که 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 ساخته شده بود، معکوس می کند. به طور خاص، ماژول هر دستورالعملی را که از پشته تماس سایه فشار می‌آورد یا بیرون می‌آید، با دستورالعمل‌های Pointer Authentication Code (PAC) که در ابتدا وجود داشت، جایگزین می‌کند.
  • تمام وصله کدهای دیگر برای ماژول غیرفعال است، از جمله کلیدهای استاتیک و بنابراین نقاط ردیابی و همچنین قلاب های فروشنده.

خودآزمایی های با پاسخ شناخته شده

هر الگوریتم پیاده‌سازی‌شده که توسط الزامات FIPS 140-3 پوشش داده می‌شود، باید قبل از استفاده، خودآزمایی با پاسخ شناخته شده انجام دهد. طبق دستورالعمل اجرایی 10.3.A FIPS 140-3 ، یک بردار آزمایشی برای هر الگوریتم با استفاده از هر یک از طول های کلید پشتیبانی شده برای رمزگذاری کافی است، تا زمانی که هم رمزگذاری و هم رمزگشایی آزمایش شوند.

Linux CryptoAPI مفهومی از اولویت‌های الگوریتم دارد، که در آن چندین پیاده‌سازی (مانند یکی با استفاده از دستورالعمل‌های رمزنگاری خاص، و یک نسخه بازگشتی برای CPUهایی که آن دستورالعمل‌ها را اجرا نمی‌کنند) از یک الگوریتم ممکن است با هم وجود داشته باشند. از این رو، نیاز به آزمایش همه پیاده سازی های یک الگوریتم وجود دارد. این امر ضروری است زیرا CryptoAPI لینوکس اجازه می‌دهد انتخاب مبتنی بر اولویت کنار گذاشته شود و به جای آن الگوریتمی با اولویت پایین‌تر انتخاب شود.

الگوریتم های موجود در ماژول

تمام الگوریتم هایی که در ماژول FIPS 140-3 گنجانده شده اند به شرح زیر فهرست شده اند. این مورد برای شاخه‌های هسته android12-5.10 ، android13-5.10 ، android13-5.15 ، android14-5.15 ، android14-6.1 و android15-6.6 اعمال می‌شود، اگرچه تفاوت‌های بین نسخه‌های هسته در موارد مناسب ذکر شده است.

الگوریتم پیاده سازی ها قابل تایید تعریف
aes aes-generic ، aes-arm64 ، aes-ce ، کتابخانه AES بله رمز بلوک ساده AES، بدون حالت کار: همه اندازه‌های کلید (128 بیت، 192 بیت و 256 بیت) پشتیبانی می‌شوند. همه پیاده‌سازی‌ها غیر از اجرای کتابخانه را می‌توان با یک حالت عملیاتی از طریق یک الگو ترکیب کرد.
cmac(aes) cmac (الگو)، cmac-aes-neon ، cmac-aes-ce بله AES-CMAC: تمام اندازه های کلید AES پشتیبانی می شوند. قالب cmac را می توان با هر پیاده سازی aes با استفاده از cmac(<aes-impl>) ساخت. سایر پیاده سازی ها مستقل هستند.
ecb(aes) ecb (الگو)، ecb-aes-neon , ecb-aes-neonbs , ecb-aes-ce بله AES-ECB: تمام اندازه های کلید AES پشتیبانی می شوند. الگوی ecb را می توان با هر پیاده سازی aes با استفاده از ecb(<aes-impl>) ساخت. سایر پیاده سازی ها مستقل هستند.
cbc(aes) cbc (الگو)، cbc-aes-neon , cbc-aes-neonbs , cbc-aes-ce بله AES-CBC: تمام اندازه های کلید AES پشتیبانی می شوند. الگوی cbc را می توان با هر پیاده سازی aes با استفاده از ctr(<aes-impl>) ساخت. سایر پیاده سازی ها مستقل هستند.
cts(cbc(aes)) cts (الگو)، cts-cbc-aes-neon , cts-cbc-aes-ce بله AES-CBC-CTS یا AES-CBC با سرقت متن رمزی: قرارداد استفاده شده CS3 است. دو بلوک متن رمزی نهایی بدون قید و شرط مبادله می شوند. تمام اندازه های کلید AES پشتیبانی می شوند. الگوی cts را می توان با هر پیاده سازی cbc با استفاده از cts(<cbc(aes)-impl>) ساخت. سایر پیاده سازی ها مستقل هستند.
ctr(aes) ctr (الگو)، ctr-aes-neon , ctr-aes-neonbs , ctr-aes-ce بله AES-CTR: تمام اندازه های کلید AES پشتیبانی می شوند. قالب ctr را می توان با هر پیاده سازی aes با استفاده از ctr(<aes-impl>) ساخت. سایر پیاده سازی ها مستقل هستند.
xts(aes) xts (الگو)، xts-aes-neon ، xts-aes-neonbs ، xts-aes-ce بله AES-XTS: در کرنل نسخه 6.1 و پایین تر، تمام اندازه های کلید AES پشتیبانی می شوند. در کرنل نسخه 6.6 و بالاتر، فقط AES-128 و AES-256 پشتیبانی می شوند. قالب xts را می توان با هر پیاده سازی ecb(aes) با استفاده از xts(<ecb(aes)-impl>) ساخت. سایر پیاده سازی ها مستقل هستند. همه پیاده‌سازی‌ها بررسی کلید ضعیف مورد نیاز FIPS را اجرا می‌کنند. یعنی کلیدهای XTS که نیمه اول و دوم آنها برابر هستند رد می شوند.
gcm(aes) gcm (الگو)، gcm-aes-ce شماره 1 AES-GCM: تمام اندازه های کلید AES پشتیبانی می شوند. فقط IV های 96 بیتی پشتیبانی می شوند. مانند سایر حالت های AES در این ماژول، تماس گیرنده مسئول ارائه IV ها است. الگوی gcm را می توان با هر پیاده سازی ctr(aes) و ghash با استفاده از gcm_base(<ctr(aes)-impl>,<ghash-impl>) ترکیب کرد. سایر پیاده سازی ها مستقل هستند.
sha1 sha1-generic ، sha1-ce بله تابع هش رمزنگاری SHA-1
sha224 sha224-generic , sha224-arm64 , sha224-ce بله تابع هش رمزنگاری SHA-224: کد با SHA-256 به اشتراک گذاشته شده است.
sha256 کتابخانه sha256-generic , sha256-arm64 , sha256-ce , SHA-256 بله تابع هش رمزنگاری SHA-256: علاوه بر رابط استاندارد CryptoAPI، یک رابط کتابخانه ای برای SHA-256 ارائه شده است. این رابط کتابخانه از پیاده سازی متفاوتی استفاده می کند.
sha384 sha384-generic , sha384-arm64 , sha384-ce بله تابع هش رمزنگاری SHA-384: کد با SHA-512 به اشتراک گذاشته شده است.
sha512 sha512-generic , sha512-arm64 , sha512-ce بله تابع هش رمزنگاری SHA-512
sha3-224 sha3-224-generic بله تابع هش رمزنگاری SHA3-224. فقط در کرنل نسخه 6.6 و بالاتر موجود است.
sha3-256 sha3-256-generic بله مانند قبل، اما با طول هضم 256 بیتی (SHA3-256). همه طول های هضم از یک پیاده سازی Keccak استفاده می کنند.
sha3-384 sha3-384-generic بله مانند قبلی، اما با طول هضم 384 بیتی (SHA3-384). همه طول های هضم از یک پیاده سازی Keccak استفاده می کنند.
sha3-512 sha3-512-generic بله مانند قبلی، اما با طول هضم 512 بیتی (SHA3-512). همه طول های هضم از یک پیاده سازی Keccak استفاده می کنند.
hmac hmac (قالب) بله HMAC (کد احراز هویت پیام هش کلیدی): الگوی hmac را می توان با هر الگوریتم یا پیاده سازی SHA با استفاده از hmac(<sha-alg>) یا hmac(<sha-impl>) ترکیب کرد.
stdrng drbg_pr_hmac_sha1 ، drbg_pr_hmac_sha256 ، drbg_pr_hmac_sha384 ، drbg_pr_hmac_sha512 بله HMAC_DRBG با تابع هش نام‌گذاری شده و با مقاومت پیش‌بینی فعال شده است: بررسی‌های سلامت گنجانده شده است. کاربران این رابط نمونه های DRBG خود را دریافت می کنند.
stdrng drbg_nopr_hmac_sha1 ، drbg_nopr_hmac_sha256 ، drbg_nopr_hmac_sha384 ، drbg_nopr_hmac_sha512 بله همانند الگوریتم‌های drbg_pr_* ، اما با مقاومت پیش‌بینی غیرفعال است. کد با نوع مقاوم در برابر پیش بینی به اشتراک گذاشته شده است. در کرنل نسخه 5.10، بالاترین اولویت DRBG drbg_nopr_hmac_sha256 است. در کرنل نسخه 5.15 و بالاتر drbg_pr_hmac_sha512 است.
jitterentropy_rng jitterentropy_rng خیر Jitter RNG ، یا نسخه 2.2.0 (نسخه هسته 6.1 و پایین تر) یا نسخه 3.4.0 (نسخه هسته 6.6 و بالاتر). کاربران این رابط، نمونه‌های Jitter RNG خود را دریافت می‌کنند. آنها از نمونه هایی که DRBG ها استفاده می کنند دوباره استفاده نمی کنند.
xcbc(aes) xcbc-aes-neon ، xcbc-aes-ce خیر
xctr(aes) xctr-aes-neon ، xctr-aes-ce خیر فقط در نسخه هسته 5.15 و بالاتر موجود است.
cbcmac(aes) cbcmac-aes-neon ، cbcmac-aes-ce خیر
essiv(cbc(aes),sha256) essiv-cbc-aes-sha256-neon , essiv-cbc-aes-sha256-ce خیر

ماژول را از منبع بسازید

برای اندروید 14 و بالاتر (از جمله android-mainline )، ماژول fips140.ko را از منبع با استفاده از دستورات زیر بسازید.

  • ساخت با بازل:

    tools/bazel run //common:fips140_dist

  • ساخت با build.sh (میراث):

    BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh

این دستورات یک ساخت کامل شامل هسته و ماژول fips140.ko را با محتویات هضم HMAC-SHA256 که در آن تعبیه شده است، انجام می دهند.

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

راهنمایی افسر کریپتو

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

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

Crypto Officer می‌تواند با راه‌اندازی مجدد دستگاه، هر زمان که بخواهید، خودآزمایی‌ها را اجرا کند.

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

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

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

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

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

  1. انتظار می‌رود که پیاده‌سازی‌های AES-GCM ماژول را می‌توان «الگوریتم تأیید کرد» اما «تأیید ماژول» را نداشت. آنها را می توان تایید کرد، اما AES-GCM را نمی توان یک الگوریتم تایید شده از دیدگاه ماژول FIPS در نظر گرفت. این به این دلیل است که الزامات ماژول FIPS برای GCM با پیاده سازی های GCM که IV های خود را تولید نمی کنند، ناسازگار است. ↩

،

هسته GKI شامل یک ماژول هسته لینوکس به نام fips140.ko است که با الزامات FIPS 140-3 برای ماژول های نرم افزار رمزنگاری مطابقت دارد. اگر محصولی که هسته GKI را اجرا می کند، این ماژول را می توان برای گواهی FIPS ارسال کرد.

الزامات FIPS 140-3 زیر باید قبل از استفاده از روال های رمزنگاری انجام شود:

  • ماژول باید یکپارچگی خود را قبل از در دسترس قرار دادن الگوریتم های رمزنگاری بررسی کند.
  • ماژول باید قبل از در دسترس قرار دادن الگوریتم های رمزنگاری تایید شده خود با استفاده از خودآزمایی های با پاسخ شناخته شده، تمرین و تأیید کند.

چرا ماژول کرنل جداگانه

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

هسته GKI قرار است به طور منظم در طول عمر پشتیبانی شده خود به روز شود. این امر باعث می شود که کل هسته در محدوده ماژول FIPS غیرممکن باشد، زیرا چنین ماژولی باید پس از هر به روز رسانی هسته مجدداً تأیید شود. تعریف "ماژول FIPS" به عنوان زیرمجموعه ای از تصویر هسته، این مشکل را کاهش می دهد، اما آن را حل نمی کند، زیرا محتویات باینری "ماژول FIPS" همچنان بسیار بیشتر از نیاز تغییر می کند.

قبل از نسخه 6.1 هسته، یکی دیگر از ملاحظات این بود که 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 ساخته شده بود، معکوس می کند. به طور خاص، ماژول هر دستورالعملی را که از پشته تماس سایه فشار می‌آورد یا بیرون می‌آید، با دستورالعمل‌های Pointer Authentication Code (PAC) که در ابتدا وجود داشت، جایگزین می‌کند.
  • تمام وصله کدهای دیگر برای ماژول غیرفعال است، از جمله کلیدهای استاتیک و بنابراین نقاط ردیابی و همچنین قلاب های فروشنده.

خودآزمایی های با پاسخ شناخته شده

هر الگوریتم پیاده‌سازی‌شده که توسط الزامات FIPS 140-3 پوشش داده می‌شود، باید قبل از استفاده، خودآزمایی با پاسخ شناخته شده انجام دهد. طبق دستورالعمل اجرایی 10.3.A FIPS 140-3 ، یک بردار آزمایشی برای هر الگوریتم با استفاده از هر یک از طول های کلید پشتیبانی شده برای رمزگذاری کافی است، تا زمانی که هم رمزگذاری و هم رمزگشایی آزمایش شوند.

Linux CryptoAPI مفهومی از اولویت‌های الگوریتم دارد، که در آن چندین پیاده‌سازی (مانند یکی با استفاده از دستورالعمل‌های رمزنگاری خاص، و یک نسخه بازگشتی برای CPUهایی که آن دستورالعمل‌ها را اجرا نمی‌کنند) از یک الگوریتم ممکن است با هم وجود داشته باشند. از این رو، نیاز به آزمایش همه پیاده سازی های یک الگوریتم وجود دارد. این امر ضروری است زیرا CryptoAPI لینوکس اجازه می‌دهد انتخاب مبتنی بر اولویت کنار گذاشته شود و به جای آن الگوریتمی با اولویت پایین‌تر انتخاب شود.

الگوریتم های موجود در ماژول

تمام الگوریتم هایی که در ماژول FIPS 140-3 گنجانده شده اند به شرح زیر فهرست شده اند. این مورد برای شاخه‌های هسته android12-5.10 ، android13-5.10 ، android13-5.15 ، android14-5.15 ، android14-6.1 و android15-6.6 اعمال می‌شود، اگرچه تفاوت‌های بین نسخه‌های هسته در موارد مناسب ذکر شده است.

الگوریتم پیاده سازی ها قابل تایید تعریف
aes aes-generic ، aes-arm64 ، aes-ce ، کتابخانه AES بله رمز بلوک ساده AES، بدون حالت کار: همه اندازه‌های کلید (128 بیت، 192 بیت و 256 بیت) پشتیبانی می‌شوند. همه پیاده‌سازی‌ها غیر از اجرای کتابخانه را می‌توان با یک حالت عملیاتی از طریق یک الگو ترکیب کرد.
cmac(aes) cmac (الگو)، cmac-aes-neon ، cmac-aes-ce بله AES-CMAC: تمام اندازه های کلید AES پشتیبانی می شوند. قالب cmac را می توان با هر پیاده سازی aes با استفاده از cmac(<aes-impl>) ساخت. سایر پیاده سازی ها مستقل هستند.
ecb(aes) ecb (الگو)، ecb-aes-neon , ecb-aes-neonbs , ecb-aes-ce بله AES-ECB: تمام اندازه های کلید AES پشتیبانی می شوند. الگوی ecb را می توان با هر پیاده سازی aes با استفاده از ecb(<aes-impl>) ساخت. سایر پیاده سازی ها مستقل هستند.
cbc(aes) cbc (الگو)، cbc-aes-neon , cbc-aes-neonbs , cbc-aes-ce بله AES-CBC: تمام اندازه های کلید AES پشتیبانی می شوند. الگوی cbc را می توان با هر پیاده سازی aes با استفاده از ctr(<aes-impl>) ساخت. سایر پیاده سازی ها مستقل هستند.
cts(cbc(aes)) cts (الگو)، cts-cbc-aes-neon , cts-cbc-aes-ce بله AES-CBC-CTS یا AES-CBC با سرقت متن رمزی: قرارداد استفاده شده CS3 است. دو بلوک متن رمزی نهایی بدون قید و شرط مبادله می شوند. تمام اندازه های کلید AES پشتیبانی می شوند. الگوی cts را می توان با هر پیاده سازی cbc با استفاده از cts(<cbc(aes)-impl>) ساخت. سایر پیاده سازی ها مستقل هستند.
ctr(aes) ctr (الگو)، ctr-aes-neon , ctr-aes-neonbs , ctr-aes-ce بله AES-CTR: تمام اندازه های کلید AES پشتیبانی می شوند. قالب ctr را می توان با هر پیاده سازی aes با استفاده از ctr(<aes-impl>) ساخت. سایر پیاده سازی ها مستقل هستند.
xts(aes) xts (الگو)، xts-aes-neon ، xts-aes-neonbs ، xts-aes-ce بله AES-XTS: در کرنل نسخه 6.1 و پایین تر، تمام اندازه های کلید AES پشتیبانی می شوند. در کرنل نسخه 6.6 و بالاتر، فقط AES-128 و AES-256 پشتیبانی می شوند. قالب xts را می توان با هر پیاده سازی ecb(aes) با استفاده از xts(<ecb(aes)-impl>) ساخت. سایر پیاده سازی ها مستقل هستند. همه پیاده‌سازی‌ها بررسی کلید ضعیف مورد نیاز FIPS را اجرا می‌کنند. یعنی کلیدهای XTS که نیمه اول و دوم آنها برابر هستند رد می شوند.
gcm(aes) gcm (الگو)، gcm-aes-ce شماره 1 AES-GCM: تمام اندازه های کلید AES پشتیبانی می شوند. فقط IV های 96 بیتی پشتیبانی می شوند. مانند سایر حالت های AES در این ماژول، تماس گیرنده مسئول ارائه IV ها است. الگوی gcm را می توان با هر پیاده سازی ctr(aes) و ghash با استفاده از gcm_base(<ctr(aes)-impl>,<ghash-impl>) ترکیب کرد. سایر پیاده سازی ها مستقل هستند.
sha1 sha1-generic ، sha1-ce بله تابع هش رمزنگاری SHA-1
sha224 sha224-generic , sha224-arm64 , sha224-ce بله تابع هش رمزنگاری SHA-224: کد با SHA-256 به اشتراک گذاشته شده است.
sha256 کتابخانه sha256-generic , sha256-arm64 , sha256-ce , SHA-256 بله تابع هش رمزنگاری SHA-256: علاوه بر رابط استاندارد CryptoAPI، یک رابط کتابخانه ای برای SHA-256 ارائه شده است. این رابط کتابخانه از پیاده سازی متفاوتی استفاده می کند.
sha384 sha384-generic , sha384-arm64 , sha384-ce بله تابع هش رمزنگاری SHA-384: کد با SHA-512 به اشتراک گذاشته شده است.
sha512 sha512-generic , sha512-arm64 , sha512-ce بله تابع هش رمزنگاری SHA-512
sha3-224 sha3-224-generic بله تابع هش رمزنگاری SHA3-224. فقط در کرنل نسخه 6.6 و بالاتر موجود است.
sha3-256 sha3-256-generic بله مانند قبل، اما با طول هضم 256 بیتی (SHA3-256). همه طول های هضم از یک پیاده سازی Keccak استفاده می کنند.
sha3-384 sha3-384-generic بله مانند قبلی، اما با طول هضم 384 بیتی (SHA3-384). همه طول های هضم از یک پیاده سازی Keccak استفاده می کنند.
sha3-512 sha3-512-generic بله مانند قبلی، اما با طول هضم 512 بیتی (SHA3-512). همه طول های هضم از یک پیاده سازی Keccak استفاده می کنند.
hmac hmac (قالب) بله HMAC (کد احراز هویت پیام هش کلیدی): الگوی hmac را می توان با هر الگوریتم یا پیاده سازی SHA با استفاده از hmac(<sha-alg>) یا hmac(<sha-impl>) ترکیب کرد.
stdrng drbg_pr_hmac_sha1 ، drbg_pr_hmac_sha256 ، drbg_pr_hmac_sha384 ، drbg_pr_hmac_sha512 بله HMAC_DRBG با تابع هش نام‌گذاری شده و با مقاومت پیش‌بینی فعال شده است: بررسی‌های سلامت گنجانده شده است. کاربران این رابط نمونه های DRBG خود را دریافت می کنند.
stdrng drbg_nopr_hmac_sha1 ، drbg_nopr_hmac_sha256 ، drbg_nopr_hmac_sha384 ، drbg_nopr_hmac_sha512 بله همانند الگوریتم‌های drbg_pr_* ، اما با مقاومت پیش‌بینی غیرفعال است. کد با نوع مقاوم در برابر پیش بینی به اشتراک گذاشته شده است. در کرنل نسخه 5.10، بالاترین اولویت DRBG drbg_nopr_hmac_sha256 است. در کرنل نسخه 5.15 و بالاتر drbg_pr_hmac_sha512 است.
jitterentropy_rng jitterentropy_rng خیر Jitter RNG ، یا نسخه 2.2.0 (نسخه هسته 6.1 و پایین تر) یا نسخه 3.4.0 (نسخه هسته 6.6 و بالاتر). کاربران این رابط، نمونه‌های Jitter RNG خود را دریافت می‌کنند. آنها از نمونه هایی که DRBG ها استفاده می کنند دوباره استفاده نمی کنند.
xcbc(aes) xcbc-aes-neon ، xcbc-aes-ce خیر
xctr(aes) xctr-aes-neon ، xctr-aes-ce خیر فقط در نسخه هسته 5.15 و بالاتر موجود است.
cbcmac(aes) cbcmac-aes-neon ، cbcmac-aes-ce خیر
essiv(cbc(aes),sha256) essiv-cbc-aes-sha256-neon , essiv-cbc-aes-sha256-ce خیر

ماژول را از منبع بسازید

برای اندروید 14 و بالاتر (از جمله android-mainline )، ماژول fips140.ko را از منبع با استفاده از دستورات زیر بسازید.

  • ساخت با بازل:

    tools/bazel run //common:fips140_dist

  • ساخت با build.sh (میراث):

    BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh

این دستورات یک ساخت کامل شامل هسته و ماژول fips140.ko را با محتویات هضم HMAC-SHA256 که در آن تعبیه شده است، انجام می دهند.

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

راهنمایی افسر کریپتو

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

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

Crypto Officer می‌تواند با راه‌اندازی مجدد دستگاه، هر زمان که بخواهید، خودآزمایی‌ها را اجرا کند.

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

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

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

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

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

  1. انتظار می‌رود که پیاده‌سازی‌های AES-GCM ماژول را می‌توان «الگوریتم تأیید کرد» اما «تأیید ماژول» را نداشت. آنها را می توان تایید کرد، اما AES-GCM را نمی توان یک الگوریتم تایید شده از دیدگاه ماژول FIPS در نظر گرفت. این به این دلیل است که الزامات ماژول FIPS برای GCM با پیاده سازی های GCM که IV های خود را تولید نمی کنند، ناسازگار است. ↩