תכונות

דף זה מכיל מידע על תכונות ההצפנה של Keystore באנדרואיד 6.0 ומעלה.

פרימיטיבים קריפטוגרפיים

Keystore מספק את הקטגוריות הבאות של פעולות:

• יצירת מפתחות
• ייבוא ​​וייצוא של מפתחות אסימטריים (ללא עטיפת מפתחות)
• ייבוא ​​של מפתחות סימטריים גולמיים (ללא עטיפת מפתחות)
• הצפנה ופענוח אסימטרית עם מצבי ריפוד מתאימים
• חתימה ואימות אסימטריים עם מצבי עיכול וריפוד מתאימים
• הצפנה ופענוח סימטריים במצבים מתאימים, כולל מצב AEAD
• יצירה ואימות של קודי אימות סימטריים של הודעות

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

בנוסף לרשימה שלמעלה, ישנו שירות אחד נוסף שהטמעות של Keymaster מספקות, אך אינו חשוף כ-API: יצירת מספרים אקראית. זה משמש באופן פנימי ליצירת מפתחות, וקטורי אתחול (IVs), ריפוד אקראי ואלמנטים אחרים של פרוטוקולים מאובטחים הדורשים אקראיות.

פרימיטיבים הכרחיים

כל ההטמעות של Keymaster מספקות:

• RSA
  • תמיכה במפתחות 2048, 3072 ו-4096 סיביות
  • תמיכה במעריך ציבורי F4 (2^16+1)
  • מצבי ריפוד עבור חתימת RSA:
    • RSASSA-PSS ( PaddingMode::RSA_PSS )
    • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
  • מצבי תקציר עבור חתימת RSA:
    • SHA-256
  • מצבי ריפוד להצפנה/פענוח RSA:
    • לא מרופד
    • RSAES-OAEP ( PaddingMode::RSA_OAEP )
    • RSAES-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
• ECDSA
  • תמיכה במפתחות של 224, 256, 384 ו-521 סיביות, באמצעות עקומות NIST P-224, P-256, P-384 ו-P-521, בהתאמה
  • מצבי תקציר עבור ECDSA:
    • אין תקציר (הוצא משימוש, יוסר בעתיד)
    • SHA-256
• AES
  • מפתחות 128 ו-256 סיביות נתמכים
  • CBC , CTR, ECB ו-GCM. הטמעת GCM אינה מאפשרת שימוש בתגיות קטנות מ-96 סיביות או באורכים לא חדים שאינם 96 סיביות.
  • מצבי ריפוד PaddingMode::NONE ו- PaddingMode::PKCS7 נתמכים עבור מצבי CBC ו-ECB. ללא ריפוד, הצפנת מצב CBC או ECB נכשלת אם הקלט אינו כפול של גודל הבלוק.
• HMAC SHA-256 , עם כל גודל מפתח עד 32 בתים לפחות.

SHA1 ושאר החברים במשפחת SHA2 (SHA-224, SHA384 ו-SHA512) מומלצים בחום עבור יישומי Keymaster. Keystore מספק אותם בתוכנה אם יישום החומרה Keymaster אינו מספק אותם.

כמה פרימיטיביים מומלצים גם עבור יכולת פעולה הדדית עם מערכות אחרות:

• גדלים קטנים יותר של מפתחות עבור RSA
• נציגי ציבור שרירותיים עבור RSA

בקרת גישה מפתח

מפתחות מבוססי חומרה שלעולם לא ניתן לחלץ מהמכשיר אינם מספקים אבטחה רבה אם תוקף יכול להשתמש בהם כרצונו (אם כי הם מאובטחים יותר ממפתחות שניתן לחלץ). לפיכך, זה חיוני ש-Keystore תאכוף בקרות גישה.

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

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

Keymaster 3 שינה את הקידומת KM_TAG לתג Tag:: .

הסוגים האפשריים כוללים:

ENUM : ערכי תגים רבים מוגדרים בספירות. לדוגמה, הערכים האפשריים של TAG::PURPOSE מוגדרים ב-enum keymaster_purpose_t .

ENUM_REP : זהה ל- ENUM , פרט לכך שהתג עשוי לחזור על עצמו ברשימת הרשאות. חזרה מציינת מספר ערכים מורשים. לדוגמה, למפתח הצפנה יש כנראה KeyPurpose::ENCRYPT ו- KeyPurpose::DECRYPT .

UINT : מספרים שלמים ללא סימנים של 32 סיביות. דוגמה: TAG::KEY_SIZE

UINT_REP : זהה ל- UINT , פרט לכך שהתג עשוי לחזור על עצמו ברשימת הרשאות. חזרה מציינת מספר ערכים מורשים.

ULONG : מספרים שלמים ללא סימנים של 64 סיביות. דוגמה: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP : זהה ל- ULONG , פרט לכך שהתג עשוי לחזור על עצמו ברשימת הרשאות. חזרה מציינת מספר ערכים מורשים.

DATE : ערכי תאריך/שעה, מבוטאים באלפיות שניות מאז 1 בינואר 1970. דוגמה: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL : נכון או לא נכון. ההנחה היא שתג מסוג BOOL הוא "false" אם התג אינו קיים ו"true" אם קיים. דוגמה: TAG::ROLLBACK_RESISTANT

BIGNUM : מספרים שלמים באורך שרירותי, המבוטאים כמערך בתים בסדר גדול. דוגמה: TAG::RSA_PUBLIC_EXPONENT

BYTES : רצף של בתים. דוגמה: TAG::ROOT_OF_TRUST

חומרה לעומת אכיפת תוכנה

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

כל ההטמעות:

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

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

בנוסף, Keystore מיישמת אכיפה מבוססת תוכנה של כל ההרשאות, בין אם הן נאכפות על ידי החומרה המאובטחת או לא.

לדוגמה, שקול מימוש מבוסס TrustZone שאינו תומך בתפוגת מפתח. ייתכן שעדיין נוצר מפתח עם תאריך תפוגה. רשימת ההרשאות של המפתח הזה תכלול את התג TAG::ORIGINATION_EXPIRE_DATETIME עם תאריך התפוגה. בקשה ל-Keystore עבור מאפייני המפתח תמצא את התג הזה ברשימת sw_enforced והחומרה המאובטחת לא תאכוף את דרישת התפוגה. עם זאת, ניסיונות להשתמש במפתח לאחר פג תוקפו יידחו על ידי Keystore.

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

למידע נוסף על קביעה אם מפתחות מגובי חומרה, ראה אישור מפתח .

הרשאות בניית הודעות קריפטוגרפיות

התגים הבאים משמשים להגדרת מאפייני ההצפנה של פעולות באמצעות המפתח המשויך: TAG::ALGORITHM , TAG::KEY_SIZE , TAG::BLOCK_MODE , TAG::PADDING , TAG::CALLER_NONCE ו- TAG::DIGEST

TAG::PADDING , TAG::DIGEST ו- PaddingMode::BLOCK_MODE ניתנים לחזרה, כלומר ערכים מרובים עשויים להיות משויכים למפתח בודד, והערך שבו יש להשתמש מצוין בזמן הפעולה.

מַטָרָה

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

• KeyPurpose::ENCRYPT
• KeyPurpose::DECRYPT
• KeyPurpose::SIGN
• KeyPurpose::VERIFY

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

ייבוא ​​וייצוא

Keymaster תומך בייצוא של מפתחות ציבוריים בלבד, בפורמט X.509, וביבוא של:

• צמדי מפתחות ציבוריים ופרטיים בפורמט PKCS#8 מקודד DER, ללא הצפנה מבוססת סיסמה
• מפתחות סימטריים כבייטים גולמיים

כדי להבטיח שניתן להבחין בין מפתחות מיובאים לבין מפתחות שנוצרו בצורה מאובטחת, TAG::ORIGIN כלול ברשימת הרשאות המפתחות המתאימה. לדוגמה, אם מפתח נוצר בחומרה מאובטחת, TAG::ORIGIN עם הערך KeyOrigin::GENERATED יימצא ברשימת hw_enforced של מאפייני המפתח, בעוד שלמפתח שיובא לחומרה מאובטחת יהיה הערך KeyOrigin::IMPORTED .

אימות משתמש

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

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

• TAG::ALL_USERS מציין שהמפתח ניתן לשימוש על ידי כל המשתמשים. אם קיימים, TAG::USER_ID ו- TAG::USER_SECURE_ID אינם קיימים.
• TAG::USER_ID יש ערך מספרי המציין את המזהה של המשתמש המורשה. שימו לב שזהו מזהה המשתמש של אנדרואיד (עבור ריבוי משתמשים), לא ה-UID של האפליקציה, והוא נאכף על ידי תוכנה לא מאובטחת בלבד. אם קיים, TAG::ALL_USERS אינו נוכח.
• TAG::USER_SECURE_ID יש ערך מספרי של 64 סיביות המציין את מזהה המשתמש המאובטח המסופק באסימון אימות מאובטח כדי לבטל את הנעילה של המפתח. אם חוזרים על המפתח, ניתן להשתמש במפתח אם אחד מהערכים מסופק באסימון אימות מאובטח.

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

• NO_AUTHENTICATION_REQUIRED מציין שלא נדרש אימות משתמש, אם כי עדיין ניתן להשתמש במפתח רק על ידי אפליקציות הפועלות כמשתמש/ים המצוינים על ידי TAG::USER_ID .
• TAG::AUTH_TIMEOUT הוא ערך מספרי המציין, בשניות, כמה טרי צריך להיות אימות המשתמש כדי לאשר שימוש במפתח. זה חל רק על פעולות מפתח פרטי/סודי. פעולות מפתח ציבורי אינן דורשות אימות. פסק זמן לא חוצה אתחולים מחדש; לאחר אתחול מחדש, כל המפתחות "לעולם לא מאומתים". פסק הזמן הקצוב עשוי להיות מוגדר לערך גדול כדי לציין שנדרש אימות פעם אחת בכל אתחול (2^32 שניות הן ~136 שנים; ככל הנראה מכשירי אנדרואיד מופעלים מחדש לעתים קרובות יותר מזה).

מחייב לקוח

כריכת לקוח, השיוך של מפתח ליישום לקוח מסוים, מתבצע באמצעות מזהה לקוח אופציונלי וכמה נתוני לקוח אופציונליים ( TAG::APPLICATION_ID ו- TAG::APPLICATION_DATA , בהתאמה). Keystore מתייחס לערכים הללו כבלאב אטום, ורק מבטיח שאותם כתמים המוצגים במהלך יצירת/ייבוא ​​מפתחות מוצגים עבור כל שימוש והם זהים בתים-בתים. נתוני מחייב הלקוח אינם מוחזרים על ידי Keymaster. המתקשר צריך לדעת את זה כדי להשתמש במפתח.

תכונה זו אינה חשופה ליישומים.

תפוגה

מאגר מפתחות תומך בהגבלת השימוש במפתח לפי תאריך. ניתן לשייך תחילת תוקף מפתח ותפוגות מפתח למפתח ו-Keymaster מסרב לבצע פעולות מפתח אם התאריך/שעה הנוכחיים נמצאים מחוץ לטווח החוקי. טווח התוקף של המפתח מצוין עם התגים TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME ו- TAG::USAGE_EXPIRE_DATETIME . ההבחנה בין "מקור" ל"שימוש" מבוססת על האם המפתח משמש ל"מקור" של טקסט צופן/חתימה/וכו', או כדי "להשתמש" בטקסט צופן/חתימה/וכו' קיים. שימו לב שההבחנה הזו אינה חשופה ליישומים.

התגים TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME ו- TAG::USAGE_EXPIRE_DATETIME הם אופציונליים. אם התגים נעדרים, ההנחה היא שתמיד ניתן להשתמש במפתח המדובר כדי לפענח/לאמת הודעות.

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

שורש אמון מחייב

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

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

מפתחות עצמאיים

חלק מהחומרה המאובטחת של Keymaster עשויה לבחור לאחסן חומר מפתח פנימי ולהחזיר ידיות במקום חומר מפתח מוצפן. או שייתכנו מקרים אחרים שבהם לא ניתן להשתמש במפתחות עד שרכיב אחר של מערכת עולם לא מאובטח או מאובטח יהיה זמין. ה-Keymaster HAL מאפשר למתקשר לבקש שמפתח יהיה "עצמאי", באמצעות התג TAG::STANDALONE , כלומר אין צורך במשאבים מלבד ה-blob ומערכת Keymaster הפועלת. ניתן לבדוק את התגים המשויכים למפתח כדי לראות אם המפתח הוא עצמאי. נכון לעכשיו, רק שני ערכים מוגדרים:

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

תכונה זו אינה חשופה ליישומים.

מְהִירוּת

כאשר הוא נוצר, ניתן לציין את מהירות השימוש המקסימלית באמצעות TAG::MIN_SECONDS_BETWEEN_OPS . יישומי TrustZone מסרבים לבצע פעולות הצפנה עם מפתח זה אם פעולה בוצעה פחות מ- TAG::MIN_SECONDS_BETWEEN_OPS שניות קודם לכן.

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

ניתן גם להגביל מפתחות ל- n שימושים לאתחול עם TAG::MAX_USES_PER_BOOT . זה גם דורש טבלת מעקב, שמכילה לפחות ארבעה מפתחות וגם נכשל בטוח. שים לב שיישומים לא יוכלו ליצור מפתחות מוגבלים לכל אתחול. תכונה זו אינה נחשפת דרך Keystore ושמורה לפעולות המערכת.

תכונה זו אינה חשופה ליישומים.

זריעה מחדש של מחולל מספרים אקראיים

מכיוון שחומרה מאובטחת מייצרת מספרים אקראיים עבור חומרי מפתח ואותחול וקטורים (IVs), ומכיוון שמחוללי מספרים אקראיים בחומרה עשויים שלא תמיד להיות אמינים לחלוטין, ה-Keymaster HAL מספק ממשק המאפשר ללקוח לספק אנטרופיה נוספת שתתערבב לתוך האקראי מספרים שנוצרו.

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

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