ארנק הזהות הדיגיטלית האירופי (EUDI Wallet) נבנה סביב אמון בארנק עצמו: מפתחות, רכיבים מאושרים, חשיפה מוגבלת של נתונים. אבל העסקה לא נגמרת שם. שירות פועל רק אחרי שצד סומך (relying party) מקבל הצגה, מאמת אותה, ומסתמך על תכונות שנבחרו.
במאמר “Who Assures the Verifier? An Executable Assurance-Locus Audit of the European Digital Identity Wallet” (arXiv:2609.26220) שואל Anton Sokolov שאלה צרה ומעשית. איזה ראיות, שניתן להריץ מחדש באופן עצמאי, מחברות גרסת מאמת ספציפית לרישום, להצגה, ולהחלטת ההסתמכות באותה עסקה?
פתיח
הטיעון אינו שצדדים סומכים אינם מוסדרים. תקנת eIDAS המעודכנת, מסמכי היישום, מסגרת הארכיטקטורה ARF 3.0.0, ומסמכי ETSI כבר מטילים חובות רישום ואימות. מסגרת ההתאמה הפונקציונלית (FCAF) מתחילה בבדיקת הארנק, וצופה בעתיד גם מערכות תחת בדיקה בצד הסומך.
הבעיה, לפי המחבר, היא תפר בראיות. יש נורמות. יש מטאדאטה של עסקה. עדיין חסר לעיתים אובייקט קטן ונייד שמראה איזו גרסת מאמת ומדיניות רצה, מול איזה מקרה שלילי קפוא, עם קוד סיבה יציב, ואיך התכונות שהתקבלו הגיעו להחלטת השירות.
1. ארבעה מוקדי ביטחון
המאמר מפריד בין ארבעה מוקדים. L1 הוא פתרון הארנק וההסמכה שלו. L2 הוא ממשל הצד הסומך: רישום, תעודות גישה, הצהרות שירות ומטרה. L3 הוא מימוש המאמת עצמו, הקוד והמדיניות שבודקים חתימה, קשירה, קהל, nonce וסטטוס. L4 היא החלטת ההסתמכות באפליקציה: קבלה, דחייה או התניה של שירות על בסיס התכונות.
כשל נפוץ אינו בהכרח באג בתוך מוקד אחד. הוא שרשרת ראיות שאינה מתחברת. רישום תקין במוקד L2 לא מוכיח קריפטוגרפיה תקינה במוקד L3. אימות מוצלח במוקד L3 לא מוכיח שבמוקד L4 השתמשו רק בתכונות שאושרו.
2. פרופיל של 17 כללים וקבלת ראיות
המחבר בנה פרופיל מחקרי עם 17 כללי סירוב מסודרים, ועם קוד קבלה אחד. הכללים מכסים שלב בקשה, שלב הצגה, ושלב הסתמכות. למשל: צד סומך לא רשום, חריגה ממאפיינים רשומים, כשל בקשירת מחזיק, אי התאמת קהל או nonce, ושימוש במורד הזרם שחורג מהתכונות שאושרו.
לכל הרצה נוצרת קבלת ראיות בפורמט JSON. היא קושרת זהות רישום, גרסאות מאמת ומדיניות, גיבוב קלט, פסק דין וקודי סיבה יציבים. כך אפשר להבדיל בין “הספרייה יודעת לבדוק” לבין “הבילד והמדיניות האלה הפיקו את הפסק הזה לקלט הקפוא הזה”.
3. 108 הרצות בלי מחלוקת, וביקורת קוד מוגבלת
נוצרו 36 עסקאות סינתטיות: שש תקינות ו30 פסולות. שלושה מימושים שונים, בפייתון, בJavaScript וב jq, הריצו את אותן עסקאות. סך הכול 108 מקרים. לא היו אי התאמות מול האורקל, ולא היו מחלוקות בין הנתיבים.
התוצאה מראה שהמודל ישים ודטרמיניסטי בניסוי. היא לא מוכיחה התאמה למוצר אמיתי או נכונות פרוטוקול מלאה. בנוסף נבדקו שלושה מאגרים ציבוריים של מאמתים. נמצאו מנגנוני אימות פרוטוקול משמעותיים, אבל לא אובייקט ראיות אחד שמחבר רישום ומטרה, גרסת מאמת מדויקת, פסק העסקה, ושימוש בתכונות במורד הזרם.
למה זה חשוב
זהות דיגיטלית היא תשתית דמוקרטית. אזרחים נותנים אמון לא רק בארנק, אלא גם בשירותים שמסתמכים עליו: רשויות, בנקים, פלטפורמות ציבוריות. אם ההסמכה מתמקדת בארנק בזמן שהמאמת והחלטת השירות נשארים בלתי ניתנים לשחזור, נשאר פער אחריות.
ההצעה במאמר זהירה. היא לא דורשת תוכנית הסמכה כבדה חדשה. היא מציעה יחידת ראיות מסוג “צד סומך כמערכת תחת בדיקה”, שמשלימה הסמכת ארנק, רישום ופיקוח. קוד סיבה יציב חשוב כאן: “לא תקין” בלי נימוק לא מאפשר השוואה בין גרסאות, בין מימושים ובין זמן.
לרגולטורים, לרוכשים ציבוריים ולמפקחים יש כאן שפה מדויקת יותר. אפשר לשאול לא רק אם הארנק מאושר, אלא גם האם ניתן להריץ מחדש את התנהגות המאמת והמדיניות מול מקרה קפוא, ולקשור אותה למטרה שנרשמה ולהחלטה שבאה אחריה.
קרדיט למאמר
Sokolov, Anton (2026). “Who Assures the Verifier? An Executable Assurance-Locus Audit of the European Digital Identity Wallet.” arXiv:2609.26220. https://arxiv.org/abs/2609.26220
הערה: הסיכום נשען על הטקסט המלא בarXiv. זה מחקר טרם ביקורת עמיתים (preprint). סקר המומחים שנרשם מראש עדיין לא נפתח לגיוס, ולכן אין כאן ממצאים מסקר.
אין תגובות:
הוסף רשומת תגובה