הקצאת מפתח מרחוק של גוגל תהיה חובה באנדרואיד 13: מה זה אומר עבורך

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

הרכיבים המרכיבים את שרשרת האמון הנוכחית באנדרואיד

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

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

סביבת ביצוע מהימנה

סביבת ביצוע מהימנה (TEE) היא אזור מאובטח ב-SoC המשמש לטיפול בנתונים קריטיים. TEE הוא חובה במכשירים שהושקו עם אנדרואיד 8 אוראו ומעלה, כלומר לכל סמארטפון עדכני יש את זה. כל דבר שאינו במסגרת ה-TEE נחשב "לא מהימן" ויכול לראות רק תוכן מוצפן. לדוגמה, תוכן מוגן DRM מוצפן עם מפתחות שניתן לגשת אליהם רק על ידי תוכנה הפועלת על ה-TEE. המעבד הראשי יכול לראות רק זרם של תוכן מוצפן, ואילו התוכן יכול להיות מפוענח על ידי ה-TEE ולאחר מכן להציג למשתמש.

ARM Trustzone

Trusty היא מערכת הפעלה מאובטחת המספקת TEE באנדרואיד, ובמערכות ARM היא עושה שימוש ב-Trustzone של ARM. Trusty מבוצע על אותו מעבד כמו מערכת ההפעלה הראשית ויש לו גישה למלוא העוצמה של המכשיר אך מבודד לחלוטין משאר הטלפון. נאמנות מורכבת מהדברים הבאים:

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

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

כַּסֶפֶת

מכשירי StrongBox הם מעבדים מאובטחים נפרדים לחלוטין, שנבנו במיוחד ומאושרים. אלה יכולים לכלול אלמנטים מאובטחים משובצים (eSE) או יחידת עיבוד מאובטחת ב-SoC (SPU). גוגל אומרת שכרגע "מומלץ בחום" StrongBox להגיע עם מכשירים שיושקו איתם אנדרואיד 12 (לפי מסמך הגדרת התאימות) מכיוון שהוא עשוי להפוך לדרישה במהדורת אנדרואיד עתידית. זהו בעצם יישום מחמיר יותר של מאגר מפתחות מגובה חומרה וניתן ליישם אותו לצד TrustZone. דוגמה למימוש של StrongBox היא שבב Titan M בסמארטפונים של Pixel. לא הרבה טלפונים עושים שימוש ב-StrongBox, ורובם עושים שימוש ב-Trustzone של ARM.

Keymaster TA

Keymaster Trusted Application (TA) הוא מנהל המפתחות המאובטח שמנהל ומבצע את כל פעולות מאגר המפתחות. זה יכול לרוץ, למשל, ב-TrustZone של ARM.

כיצד אישור מפתח משתנה עם אנדרואיד 12 ואנדרואיד 13

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

הזן הקצאת מפתח מרחוק. החל באנדרואיד 12, גוגל מחליפה את הקצאת המפתח הפרטי במפעל בשילוב של חילוץ מפתח ציבורי במפעל ואספקת אישורים באוויר עם זמן קצר תעודות. תוכנית זו תידרש באנדרואיד 13, ויש לה כמה יתרונות. בראש ובראשונה, זה מונע מיצרני OEM ו-ODM את הצורך לנהל סודיות מפתח במפעל. שנית, היא מאפשרת לשחזר מכשירים אם המפתחות שלהם ייפגעו, כלומר, הצרכנים לא יאבדו גישה לשירותים מוגנים לנצח. כעת, במקום להשתמש בתעודה המחושבת באמצעות מפתח שנמצא במכשיר ועלול להיות דלוף דרך א פגיעות, אישור זמני מתבקש מ-Google בכל פעם ששירות הדורש אישור בשימוש.

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

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

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

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

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

יצרנו קשר עם גוגל ושאלנו אם יש לזה רלוונטיות ל-Widevine DRM וכיצד חלק ממשתמשי Pixel דיווחו על שדרוג לאחור של רמת ה-DRM שלהם עם טוען אתחול נעול. שאלנו גם אם ניתן להפיץ את זה כשדרוג OTA למשתמשים דרך שירותי Google Play עכשיו. אנו נדאג לעדכן מאמר זה אם נשמע בחזרה. לא ברור אילו מרכיבים בשרשרת האמון הנוכחית יושפעו או באיזה אופן.

---

מָקוֹר: גוגל