מודול הצפנה 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. באופן ספציפי, המודול מחליף הוראות דחיפה או קפיצה מערימת האזורים הכהים באמצעות קוד אימות המצביע הוראות (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 (תבנית), cts-cbc-aes-neon, cts-cbc-aes-ce כן AES-CBC-CTS או AES-CBC עם גניבת מידע מוצפן (ciphertext): המוסכמה שבה נעשה שימוש היא CS3; שני הבלוקים האחרונים של מידע מוצפן (ciphertext) מוחלפים ללא תנאי.יש תמיכה בכל הגדלים של מפתחות 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 (תבנית), 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 כן פונקציית גיבוב קריפטוגרפי 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. קיים רק בגרסת ליבה (kernel) 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 (קוד אימות הודעות עם גיבוב (Keyed-Hash)): אפשר להרכיב את התבנית 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. בגרסת ליבה (kernel) 5.15 ואילך היא drbg_pr_hmac_sha512.
jitterentropy_rng jitterentropy_rng לא Jitter RNG, גרסה 2.2.0 (גרסה 6.1 ומטה) או גרסה 3.4.0 (גרסה 6.6 ואילך של ליבה). למשתמשים בממשק הזה יש מכונות RNG משלהם. הם לא עושים שימוש חוזר במכונות שבהן נעשה שימוש ב-DRBG.
xcbc(aes) xcbc-aes-neon, xcbc-aes-ce לא
xctr(aes) xctr-aes-neon, xctr-aes-ce לא קיים רק בגרסת ליבה (kernel) 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) פאניקה והמכשיר לא ממשיך באתחול. אם הפעלה מחדש של המכשיר כן לא תפתור את הבעיה, המכשיר חייב לאתחל במצב שחזור כדי לתקן את בעיה בהבהוב מחדש של המכשיר.


  1. הציפייה היא שהטמעות AES-GCM של המודול יכולות להיות "אלגוריתם". אושר" אבל לא "המודול אושר". אפשר לאמת אותם, אבל AES-GCM לא יכול להיחשב כאלגוריתם מאושר מבחינת מודול FIPS. הסיבה לכך היא שדרישות מודול FIPS עבור GCM אינן תואמות הטמעות GCM שלא יוצרות מערכות IV אחרות משלהן.