אימות ללא פנייה לשרת: מדוע ה-IDP הדיגיטלי הבינלאומי העתידי אינו צריך לפנות למנפיק בכל שימוש

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

כמעט כל הצעה לזהות דיגיטלית מכילה את אותו המשפט המרגיע:

“ניתן לאמת את האישור באופן מיידי.”

לפעמים משפט זה מתאר התקדמות אמיתית. לפעמים הוא מתאר מעקב עם ממשק משתמש ידידותי יותר.

הסטנדרטים המפורסמים כיום כבר מבהירים שמאמת אינו צריך ליצור קשר עם המנפיק בכל פעם שמוצג אישור:

• ארכיטקטורת ה-mDL הנוכחית של NIST קובעת שמאמת יכול לאשר אותנטיות ושלמות על ידי אמון בחתימת המנפיק ובמפתחות הציבוריים שלו, ללא כל קשר ישיר עם המנפיק.
• AAMVA מאשר ש-ISO/IEC 18013-5 מחייב תמיכה באחזור מהמכשיר ומתיר אחזור מהשרת רק באופן אופציונלי.
• AAMVA גם מזהיר שבאחזור מהשרת, הרשות המנפיקה מעורבת בזמן אמת בכל שימוש — כלומר היא יכולה מבחינה טכנית לרשום מתי האישור משמש, אילו נתונים משותפים, ואף להסיק מיקום מניתוח כתובות IP.

זו אינה הערת שוליים משנית. זוהי שאלת העיצוב המרכזית לדור הבא של אישורי נהיגה חוצי-גבולות.

קיצור הדרך המסוכן: צמצום ארבע שאלות לקריאת רשת אחת

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

1. האם האישור אותנטי?
2. האם האדם שמציג אותו הוא בעל הזכות הלגיטימי?
3. האם האישור עצמו עדיין בתוקף?
4. האם זכות הנהיגה הלאומית הבסיסית עדיין בתוקף?

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

אותנטיות צריכה להיות מאומתת מקומית, לא דרך הרשת

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

• מודל האמון של mDL מבית NIST קובע שאותנטיות ושלמות מאומתות על בסיס חתימת המנפיק ומפתחות ציבוריים — ללא צורך בקשר חי עם המנפיק.
• שירות האמון הדיגיטלי של AAMVA קיים בדיוק כדי לתת למאמתים גישה למפתחות ציבוריים תקפים של המנפיק ללא callbacks לכל עסקה.

עיקרון עיצוב 1: אל תשתמש בקישוריות חיה כדי לפתור בעיה שחתימות כבר פותרות.

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

קישור לבעלים צריך להיות מוכח מקומית, לא מדווח גלובלית

השאלה השנייה — האם זהו בעל הזכות הלגיטימי? — גם לה יש תשובה שאינה דורשת רשת.

ארכיטקטורת EUDI הנוכחית מחייבת קישור למכשיר עבור PIDs ואישורי ISO/IEC 18013-5. המאמת מבקש מהארנק לחתום על אתגר חדש באמצעות המפתח הפרטי התואם למפתח הציבורי המוטמע באישור:

• ב-ISO/IEC 18013-5 זה נקרא אימות mdoc.
• ב-SD-JWT VC זה נקרא קישור מפתח.

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

עיקרון עיצוב 2: הוכח חזקה מקומית. אל תוכיח זהות גלובלית.

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

סטטוס האישור וסטטוס זכות הנהיגה הם שני דברים שונים

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

מפרט Bitstring Status List של W3C מבהיר זאת: מידע הסטטוס המצורף לאישור ניתן לאימות חל על האישור הניתן לאימות עצמו — לא בהכרח על הזכות בעולם האמיתי הבסיסית. אישור דיגיטלי עשוי להיות מבוטל בגלל שמנגנון החתימה שלו נפרץ, בעוד שזכות הנהיגה הבסיסית עדיין תקפה לחלוטין.

לפיכך, IDP עתידי זקוק לשתי שכבות סטטוס נפרדות:

• שכבת סטטוס האישור — עבור האישור הדיגיטלי או ערוץ ההצגה עצמו.
• שכבת זכות הנהיגה — עבור הזכות הלאומית הבסיסית לנהוג.

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

פגיעה בארנק צריכה להתפשט דרך הסטטוס — לא להפעיל callbacks בצד המאמת

IDP עתידי זקוק גם לתשובה ברורה למה שקורה כאשר ארנק נפרץ.

ארכיטקטורת EUDI מספקת אחת:

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

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

שלושה דפוסי ביטול תוקף ישימים (ללא Callbacks)

EUDI מחייב ספקים להשתמש באחת משלוש שיטות ביטול תוקף:

• אישורים לטווח קצר — תקפים ל-24 שעות או פחות, כך שביטול תוקף הופך מיותר.
• רשימת סטטוס אישורים — רשימה מפורסמת שמאמתים יכולים להתייעץ איתה.
• רשימת ביטול אישורים — רשימה מפורשת של אישורים שבוטלו.

עבור אישורים בתוקף מעל 24 שעות, EUDI מחייב הטמעת מידע ביטול תוקף הכולל:

• כתובת URL שממנה צדדים מסתמכים יכולים לאחזר את רשימת הסטטוס.
• מזהה המאתר את האישור ברשימה זו.

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

המסקנה: ביטול תוקף אינו מנגנון יחיד, ובוודאי אינו הצדקה ל-callbacks חובה למנפיק.

קצר-טווח כברירת מחדל, ארוך-טווח רק כשנדרש

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

• EUDI קובע שאישורים בתוקף ל-24 שעות או פחות אינם דורשים תשתית ביטול תוקף — הם פגים לפני שביטול תוקף יהיה רלוונטי.
• W3C קובע שהצגות ניתנות לאימות הן בדרך כלל קצרות מועד ואינן מיועדות לאחסון לטווח ארוך.
• NIST מזהיר במפורש מפני שידור חוזר ונשנה של מזהים שניתן לעשות בהם שימוש חוזר לשימוש יומיומי. אימות יומיומי צריך להסתמך על טכנולוגיות שנבנו לצורך זה, כגון passkeys, לא הצגה חוזרת של אישור עשיר בזהות.
• NIST גם בחר באימות מכשיר מקומי על פני התאמה ביומטרית בצד השרת, בדיוק משום שאימות מקומי שומר על פרטיות ויעיל יותר מבחינה תפעולית.

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

רשימות סטטוס הן מנגנון ברירת המחדל הנכון

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

Bitstring Status List v1.0 של W3C מתאר מנגנון המשמר פרטיות, יעיל בשטח ובעל ביצועים גבוהים לפרסום נתוני סטטוס כגון השעיה או ביטול תוקף. מאפיינים מרכזיים כוללים:

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

זה מעביר את השאלה מ:

“האם אני יכול לשאול את המנפיק על משתמש זה עכשיו?”

ל:

“האם כבר יש לי רשימת סטטוס עדכנית מספיק המשמרת פרטיות כדי להחליט מקומית?”

זו שאלה טובה בהרבה — הן מבחינה טכנית והן מבחינה פוליטית.

“ללא פנייה לשרת” הוא דפוס הורדה, לא סיסמה

הכלל החשוב ביותר בהנחיות הפרטיות של EUDI הוא פרוצדורלי, לא פילוסופי.

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

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

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

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

פרטיות קבוצתית: הדרישה שרוב העיצובים שוכחים

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

דרישות הפרטיות של EUDI מציינות כי:

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

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

פעולה לא מקוונת אינה מקרה קצה — היא דרישת ליבה

כל מערכת נסיעות שמניחה קישוריות מושלמת מעוצבת בצורה גרועה.

• AAMVA מאשר שאחזור מהמכשיר עובד ללא קישוריות חיצונית הן למכשיר הבעלים והן לקורא, וש-ISO/IEC 18013-5 מחייב תמיכה באחזור מהמכשיר.
• EUDI מקבל שצדדים מסתמכים עשויים להיות לא מקוונים וחסרי רשימת סטטוס שמורה, ובמקרה כזה הוא ממליץ על ניתוח סיכונים לפני קבלת החלטה.

קבל פשרה זו מוקדם:

לא ניתן לקבל פעולה לא מקוונת מושלמת ורעננות בזמן אמת מושלמת בו-זמנית.

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

יומני רישום הם המקום שבו הפרטיות נכשלת בשקט

אפילו ארכיטקטורת סטטוס מצוינת יכולה להיהרס על ידי רישום רשלני.

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

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

ארכיטקטורת ה-IDP ללא פנייה לשרת — מוחשית

בהרכבת העקרונות יחד, הנה מה שהמערכת צריכה לעשות בפועל:

1. הנפק אישור בסיס מקושר למכשיר. קשור את האישור למפתחות המוגנים בסביבה המאובטחת של הארנק — חובה תחת EUDI עבור PIDs ואישורי ISO/IEC 18013-5.
2. בקש רק מה שנדרש, עם אתגר חדש. בעסקת OpenID4VP, שאילתת DCQL מאפשרת לארנק להראות לבעלים אילו תכונות מתבקשות, והמאמת מנפיק אתגר למניעת replay (על פי ארכיטקטורת ה-mDL הנוכחית של NIST).
3. צור הצגה קצרת-מועד, לא מזהה לשימוש חוזר. כל הצגה צריכה להיות ספציפית למאמת, לבקשה ולרגע.
4. אמת אותנטיות מקומית. אמת חתימות מנפיק ומפתחות ציבוריים לא מקוון; שירות האמון של AAMVA נבנה בדיוק לכך.
5. בדוק סטטוס מרשימות שמורות שמתרעננות בנפרד. כאשר אישורים ארוכים מדי מכדי לוותר על ביטול תוקף, השתמש ברשימות סטטוס שמורות מקומית שמתרעננות לפי לוח זמנים שאינו קשור להצגות משתמש.
6. החל מדיניות סיכון כאשר רעננות אינה זמינה. הפוך החלטות לא מקוונות למדיניות מאמת מפורשת, לא לניחושים לא מובנים.
7. מחק נתוני מעקב באגרסיביות. השלך אלמנטים ייחודיים לעסקה וחותמות זמן כאשר אינם נחוצים עוד; אל תשמור יומנים שיכולים לשחזר היסטוריית תנועה.

כך נראית ארכיטקטורה רצינית ללא פנייה לשרת — שכבתית, משמרת פרטיות, קריפטוגרפית-מקומית, וכנה מבחינה תפעולית לגבי מציאות לא מקוונת.

שלושה דפוסים שצריכים להיות אסורים מעיצוב

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

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

הטיעון המרכזי במשפט אחד

אימות מיידי אסור שיהפוך לרשות למעקב בצד המנפיק.

IDP עתידי צריך להיות מסוגל:

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

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

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

זה בדיוק מה שה-IDP העתידי צריך לסרב להיות.

שאלות נפוצות

מהו “אימות עם פנייה לשרת”?
זהו כל עיצוב שבו מאמת יוצר קשר עם המנפיק בזמן אמת כדי לאמת אישור. בעוד שהוא פותר אותנטיות וביטול תוקף בו-זמנית, הוא גם מאפשר למנפיק לצפות בכל אירוע הצגה.

האם ISO/IEC 18013-5 מחייב קשר מקוון עם המנפיק?
לא. AAMVA מאשר ש-ISO/IEC 18013-5 מחייב תמיכה באחזור מהמכשיר ומתיר אחזור מהשרת רק באופן אופציונלי.

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

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

האם אימות לא מקוון הוא אכן מעשי?
כן — וגופי תקנים כולל AAMVA ו-EUDI מחייבים זאת במפורש. הפשרה היא שרעננות בזמן אמת מושלמת אינה תואמת לפעולה לא מקוונת מושלמת, לכן רעננות חייבת להיות החלטת מדיניות, לא תלות קשיחה.