מודול קריפטוגרפיה של GKI עם אישור FIPS 140-3

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

הליבה של GKI כוללת מודול הליבה של Linux בשם fips140.ko שתואם ל- דרישות של FIPS 140-3 למודולים של תוכנות קריפטוגרפיות. אפשר לשלוח את המודול הזה לאישור FIPS אם המוצר שבו פועל הליבה של GKI מחייב זאת.

חובה לעמוד במיוחד בדרישות הבאות של FIPS 140-3 לפני אפשר להשתמש בתרחישים של הצפנה:

• המודול צריך לבדוק את תקינות הקוד שלו לפני שהוא מאפשר גישה לאלגוריתמים קריפטוגרפיים.
• לפני שהמודול יהיה זמין, צריך להפעיל את האלגוריתמים הקריפטוגרפיים המאושרים שלו ולאמת אותם באמצעות בדיקות עצמיות עם תשובה ידועה.

למה מודול נפרד בליבה

תיקוף של אישור FIPS 140-3 מבוסס על הרעיון שמרגע שתוכנה או חומרה שמבוסס על האישור, הוא לא השתנה. אם משנים, הוא חייב להיות אושר מחדש. הדרישה הזו לא תואמת בקלות לתהליכי פיתוח התוכנה שבשימוש כיום, וכתוצאה מכך, בדרך כלל מודולים של תוכנות FIPS מתמקדים ככל האפשר ברכיבים הקריפטוגרפיים, כדי להבטיח ששינויים שלא קשורים לקריפטוגרפיה לא ידרשו הערכה מחדש של הקריפטוגרפיה.

הליבה של GKI אמורה להתעדכן באופן קבוע לאורך כל מחזור החיים הנתמך שלה. כתוצאה מכך לא אפשרי שכל הליבה תהיה במסגרת ה-FIPS את גבולות המודול, ולכן המודול הזה יצטרך לעבור אישור מחדש בכל ליבה הגדרה של 'מודול FIPS' תהיה תת-קבוצה של תמונת הליבה מצמצמים את הבעיה אבל לא פותרים אותה, כי התוכן הבינארי "מודול FIPS" עדיין ישתנה בתדירות גבוהה בהרבה מהנדרש.

לפני גרסת הליבה 6.1, שיקול נוסף היה ש-GKI הורכבה עם LTO (אופטימיזציה של זמן קישור) הופעלה, מכיוון ש-LTO הייתה דרישה מוקדמת עבור Control תקינות הזרימה, שהיא תכונת אבטחה חשובה.

לכן, כל הקוד שמכוסה בדרישות FIPS 140-3 ארוז למודול ליבה נפרד fips140.ko, שמסתמך רק על יציב מהממשקים שנחשפו על ידי מקור הליבה של GKI שממנו הוא נוצר. המשמעות היא שאפשר להשתמש במודול במהדורות שונות של GKI מאותה דור, וצריך לעדכן אותו ולשלוח אותו מחדש לצורך אישור רק אם תוקנו בעיות בקוד שכלול במודול עצמו.

מתי להשתמש במודול

הליבה של GKI עצמה מכילה קוד שמבוסס על תוכניות הקריפטוגרפיה שגם הן נכללות בחבילה של מודול הליבה FIPS 140-3. לכן, פונקציות הקריפטוגרפיה המובנות לא מועברות מליבת GKI, אלא מועתקות למודול. כשהמודול נטען, תרחישי הקריפטו המובנים בוטלה על ידי Linux CryptoAPI, ומוחלפות על ידי הפרוטוקולים שהועברו על ידי של מודל טרנספורמר.

כלומר, המודול fips140.ko הוא אופציונלי לחלוטין, והוא מאפשר כדאי לפרוס אותו אם נדרש אישור FIPS 140-3. בנוסף, המודול לא מספק יכולות נוספות, וטעינה שלו ללא צורך צפויה להשפיע רק על זמן האתחול, בלי להניב תועלת כלשהי.

איך לפרוס את המודול

כדי לשלב את המודול ב-build של 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.
• המודול מבטל את כל תיקוני הקוד שבוצעו על ידי הליבה (kernel) של דינמי Shadow Call Stack. באופן ספציפי, המודול מחליף את כל ההוראות שמבצעות דחיפה או הוצאה (pop) מ-shadow call stack בהוראות של Pointer Authentication Code‏ (PAC) שהיו קיימות במקור.
• כל שאר תיקוני הקוד מושבתים עבור המודול, כולל מפתחות סטטיים ולכן נקודות מעקב וגם קטעי הוק (hooks) של ספקים.

הבדיקות העצמאיות עם תשובה ידועה

כל אלגוריתמים מוטמעים שעומדים בדרישות של FIPS 140-3 לבצע בדיקה עצמית של תשובה ידועה לפני השימוש. לפי FIPS 140-3 הנחיות להטמעה 10.3.A, וקטור בדיקה יחיד לכל אלגוריתם שמשתמש באחד מאורכי המפתח הנתמכים מספיקים להצפנה, כל עוד בודקים גם את ההצפנה וגם את הפענוח.

ל-Linux CryptoAPI יש תפיסה של סדר עדיפויות של אלגוריתם, כאשר הטמעות (למשל, הטמעה באמצעות הוראות קריפטו מיוחדות, וחלופה למעבדי CPU שבהם ההוראות האלה לא מיושמות) של אותו אלגוריתם. מתקיימים יחד. לכן, צריך לבדוק את כל ההטמעות של אותו אלגוריתם. הדבר נחוץ כי Linux 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 (template),‏ 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: בגרסאות ליבה (kernel) 6.1 ומטה, יש תמיכה בכל הגדלים של מפתחות AES; בגרסת ליבה (kernel) 6.6 ואילך, רק AES-128 ו-AES-256 נתמכים. אפשר ליצור תבנית xts עם כל הטמעה של ecb(aes) באמצעות xts(<ecb(aes)-impl>). יישומים אחרים הם נפרדים. בכל ההטמעות מיושמת בדיקת המפתחות החלשה שנדרשת על ידי FIPS. כלומר, נדחה מפתחות XTS שהמחצית הראשונה והשניה שלהם שוות.
gcm(aes)	gcm (template),‏ gcm-aes-ce	לא1	AES-GCM: יש תמיכה בכל הגדלים של מפתחות AES. יש תמיכה רק ב-IVs של 96 ביט. כמו בכל מצבי AES האחרים במודול הזה, מבצע הקריאה החוזרת אחראי לספק את מספר ה-IV. אפשר ליצור את התבנית gcm באמצעות כל הטמעות של ctr(aes) ו-ghash באמצעות gcm_base(<ctr(aes)-impl>,<ghash-impl>). יישומים אחרים הם נפרדים.
sha1	sha1-generic, sha1-ce	כן	פונקציית גיבוב (hash) קריפטוגרפית מסוג SHA-1
sha224	sha224-generic, sha224-arm64 sha224-ce	כן	פונקציית גיבוב (hash) קריפטוגרפית מסוג SHA-224: הקוד משותף עם האלגוריתם SHA-256.
sha256	sha256-generic, sha256-arm64, sha256-ce, ספריית SHA-256	כן	פונקציית גיבוב (hash) קריפטוגרפית מסוג SHA-256: ממשק ספרייה מסופק ל-SHA-256 בנוסף לממשק CryptoAPI הסטנדרטי. בממשק הספרייה הזה נעשה שימוש בהטמעה אחרת.
sha384	sha384-generic, sha384-arm64 sha384-ce	כן	פונקציית גיבוב (hash) קריפטוגרפית מסוג SHA-384: הקוד משותף עם האלגוריתם SHA-512.
sha512	sha512-generic, sha512-arm64 sha512-ce	כן	פונקציית גיבוב (hash) קריפטוגרפית מסוג SHA-512
sha3-224	sha3-224-generic	כן	פונקציית גיבוב (hash) קריפטוגרפית מסוג 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 או הטמעה של 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 נוצר באמצעות פונקציית הגיבוב (hash) בעלת השם ועם העמידות לחיזוי מופעלת: בדיקות תקינות נכללות. למשתמשים בממשק הזה יש מכונות 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. בגרסת ליבה (kernel) 5.15 ואילך היא drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	לא	Jitter RNG, גרסה 2.2.0 (גרסת ליבה 6.1 ומטה) או גרסה 3.4.0 (גרסת ליבה 6.6 ומעלה). למשתמשים בממשק הזה יש מכונות RNG נפרדות של Jitter RNG. הם לא משתמשים שוב במכונות שבהן ה-DRBGs משתמשים.
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	לא

פיתוח המודול מקוד המקור

ב-Android מגרסה 14 ואילך (כולל android-mainline), צריך ליצור את המודול fips140.ko מהמקור באמצעות הפקודות הבאות.

• בונים בעזרת Bazel:

  tools/bazel run //common:fips140_dist

• פיתוח גרסה זמינה להתקנה (build) עם build.sh (דור קודם):

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

הפקודות האלה מבצעות build מלא שכולל את הליבה ואת המודול fips140.ko עם תוכן הדיגסט של HMAC-SHA256 שמוטמע בו.

הנחיות למשתמשי קצה

הדרכה לגבי מנהלי מטבעות וירטואליים

כדי להפעיל את מודול הליבה, מערכת ההפעלה צריכה להיות מוגבלת למצב הפעלה של אופרטורים יחידים. מערכת Android מטפלת בזה באופן אוטומטי באמצעות חומרת ניהול זיכרון במעבד.

לא ניתן להתקין את מודול הליבה בנפרד. הוא נכלל כחלק מתוכנת הקושחה של המכשיר ונטען באופן אוטומטי בזמן האתחול. הוא פועל רק במצב עבודה מאושר.

מנהל הקריפטו יכול לגרום לביצוע הבדיקות העצמיות בכל שלב על ידי הפעלה מחדש במכשיר.

הנחיות למשתמשים

משתמש מודול הליבה הם רכיבים אחרים של הליבה שצריכים להשתמש באלגוריתם קריפטוגרפיים. מודול הליבה לא מספק לוגיקה נוספת לשימוש באלגוריתמים, ולא מאחסן פרמטרים מעבר לזמן הנדרש לביצוע פעולה קריפטוגרפית.

השימוש באלגוריתמים למטרות תאימות ל-FIPS מוגבל לאישור אלגוריתמים. כדי לעמוד בדרישת 'מדד השירות' של FIPS 140-3, המודול מספק פונקציה fips140_is_approved_service שמציינת אם אלגוריתם מאושר.

שגיאות בבדיקות עצמיות

במקרה של כשל בבדיקה עצמית, מודול הליבה גורם לליבה (kernel) פאניקה והמכשיר לא ממשיך באתחול. אם הפעלה מחדש של המכשיר לא פותרת את הבעיה, צריך להפעיל את המכשיר במצב שחזור כדי לתקן את הבעיה באמצעות מחיקת נתונים והפעלה מחדש (flash) של המכשיר.