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

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

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

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

המאמר הזה מעבד מצגת שהוצגה ל-NGI TrustChain בספטמבר 2024. הטענה המרכזית פשוטה: הוכחות אפס ידע הן אבן בניין חשובה להשתתפות אזרחית פרטית, אבל פרטיות המשתמש היא מאפיין של כל המערכת.

למה זהות נכנסת לפלטפורמות אזרחיות

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

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

יש כמה דרכים להגיע לעמידות בפני Sybil, ולכל אחת פשרות:

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

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

מה הוכחות אפס ידע עושות היטב

בזרימת credential פשוטה יש שלושה צדדים:

המנפיק מאשר משהו לגבי אדם ומנפיק credential.
המחזיק שומר את ה-credential ומחליט מתי להשתמש בו.
המאמת בודק הוכחה שנגזרת מה-credential.

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

כמה גישות טכניות תומכות בדפוס הזה. BBS+ credentials מאפשרים חשיפה סלקטיבית והוכחות שאינן ניתנות לקישור. גישות אחרות משתמשות ב-Merkle וב-ZK-SNARKs כדי להפוך פורמטים שניתנים יותר לקישור לפרטיים יותר. zkVM כלליים עשויים בעתיד להקל על הוכחת עובדות לגבי credentials קיימים הממוקדים באבטחה.

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

זה פותר בעיה חשובה. זה לא פותר את כל בעיות הפרטיות.

מודל האיום: המחזיק קודם

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

לכן נדרש מודל איום מחמיר יותר מזה של רוב הפלטפורמות החברתיות כיום:

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

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

שאר קרחון הפרטיות

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

חשיפת יתר

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

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

מטא-דאטה של הרשת

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

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

Cookies ומתווכי נתונים

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

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

דוא"ל, טלפון ושחזור חשבון

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

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

מזהים קבועים

הוכחת אפס ידע עדיין יכולה להיות מקושרת אם אותו מזהה קבוע מופיע סביבה. כתובות ארנק, DIDs, subject IDs של credential, מזהי מכשיר או account IDs יציבים יכולים כולם להפוך לידיות קורלציה.

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

קורלציה לפי זמן

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

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

ארנקים, מכשירים וסיכוני שרשרת אספקה

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

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

הסקה התנהגותית

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

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

ארכיטקטורה טובה יותר לאינטראקציות ZK אנונימיות באופן אמין

זרימת credential שמגינה על פרטיות צריכה להיות מתוכננת מתוך הנחה שהמאמת רוצה לדעת יותר ממה שמותר לו.

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

לבקש את ההוכחה הכי פחות מדויקת שמספקת את הדרישה האזרחית.
להימנע משילוב הצגת הוכחה עם זרימות חשבון מזהות.
לא לקשור טלפונים, דוא"ל, כתובות ארנק או DIDs קבועים לאירועי הוכחה אלא אם מקרה השימוש באמת דורש זאת.
להשאיר cookies של צד שלישי, אנליטיקה ו-trackers מחוץ לזרימת ההוכחה.
לצמצם לוגים, במיוחד כתובות IP, חותמות זמן ומטא-דאטה של בקשות.
להשתמש בכינויים ייחודיים להקשר כאשר נדרשת השתתפות מתמשכת.
להפוך את frontend המאמת, לוגיקת בקשת ההוכחה, אינטגרציות הארנק וה-SDKs לקוד פתוח וברי-ביקורת.
להפוך בקשות הוכחה למובנות למשתמשים, כדי שיראו מה מוכח ומה אינו נחשף.
למנוע callbacks למנפיק או מנגנונים אחרים שיאפשרו לו לדעת היכן credentials משמשים.

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

אתגרים פתוחים

עדיין יש עבודה קשה.

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

שנית, אקוסיסטם ה-credentials מפוצל. BBS+, SD-JWT, רישיונות נהיגה ניידים, שבבי דרכון, credentials שעברו Merkle והוכחות מבוססות zkVM עושים פשרות שונות. פלטפורמות אזרחיות צריכות אינטרופרביליות בלי לרדת למכנה המשותף הנמוך ביותר של פרטיות.

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

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

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

סיכום

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

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

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

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