אני בונה מערכות ל25 שנים, ואני אוהב לבנות דברים שנועדו לעיצוב מכוון ויעילות תפעולית, נושא רק את כמות הווקטור שמקבלת את משקלה.
בגישה זו, המינימיזציה של מה שאני מאחסן ממידע המשתמש תמיד הייתה הגיונית עבורי, סיבות שעולות מעבר לחדירה הברורה. ריבונות הנתונים שלהם חשובה. מתחת לזה יש משהו פשוט יותר: דברים שייכים למקום שבו הם שייכים. רוב מה שאני בונה הוא עיבוד, וארכיטקטורת עיבוד לא תופעל כמשהו אחר. שמירת רשומה שלא נדרשה היא וקטור שלא מרוויח דבר. הטיפול בכך כייעול, ולא כתרגיל התאמה, הוא מה שמחזיק את העיצוב כנה — ומערכת שנבנתה כך נוטה להישאר במצב טוב עם הרגולציה בעצמה, מכיוון שיש מעט מאוד מהשאר לרגולציה.
אז כאשר Mary הכרזת Camacho הגיעה לתוך הזרם שלי ב-X, קראתי את הארכיטקטורה שלה כפי שקראתי את שלי. היא פרסמה את הליבה שלה ברשומה הציבורית תחת רישיון Creative Commons, ברמת הפרטים שהמהנדס צריך כדי לבנות אותה מחדש, והיא הייתה ישירה לגבי האמנות הקודמת שעליה היא מבוססת.
בעבודה דרך הסדרה, הצבתי ישות יריבה בתוך השרת ופעלתי מה שהייתה יכולה להגיע. היא יכלה לחרוג מהעובד.
כמעט כל העבודה שהשלה התבצעה כקשר קולי — על 30 הערות קוליות, חושבת בקול רם ובודקת את הדאגה מזוויות שונות עד שהיא או נשארת או מתפרקת.

מה שמצאתי: המכשיר מאפיין למי שמרשום את רשומת הטענה ראשון

ההצהרה מפרטת את סדר הפעולות ישירות. העובד טוען את העבודה ומפרסם את המפתח שלו, ורק אז המכשיר מאפיין:
  1. עובד → תיאום: סקר וטענה את העבודה (כתיבה-פעם-אחת, ראשון-זוכה), מפרסם את המפתח הציבורי של העובד.
  2. מכשיר ← תיאום: סקר, קבל את המפתח הציבורי של העובד, נגזר הסוד המשותף, מאפיין את_payload.
— §2.1, זרימת נתונים (לפי עבודה)
צד המכשיר של ההסכם הזה מוגדר בדיוק שווה:
המכשיר, בלמידה של המפתח הציבורי של העובד, מבצע את החלפה X25519 שלו ו-ML-KEM encapsulation נגד המפתח של העובד, מייצר את התרומה הציבורית שלו (מפתח ציבורי X25519 ‖ ML-KEM ciphertext) והסוד המשותף.
— §4.2, קישור למחזור חיי העובד
בלמידה. על פני 19 דפים אין חתימה על המפתח הציבורי הזמני של העובד, אין תעודה, אין אישור שהמכשיר מעריך, ואין סוד משותף מקדים. החסרון הוא מכוון ומוצג ככוח: הדגם מקבל פענוח ללא מסמך אישור, ציטוט TPM, או אובייקט boot מדוד, והוא אינו שומר סוד עובד מקדים.
לכן המכשיר מאפיין את_payload שלו לכל מפתח ציבורי שנמצא ברשומת הטענה, ללא אמצעי להבדיל מפתח עובד לגיטימי מכולם אחרים. כל צד שיכול לכתוב טענה ראשון הופך להיות הצד שהמכשיר מאפיין אליו, וה_payload המועבר פותח בידיהם.
Diagram source
flowchart TB
    subgraph BEFORE["לפני: כפי שפורסם"]
        direction LR
        A2{"מי טוען ראשון?"} -->|עובד אמיתי| A3["מפתח אמיתי"]
        A2 -->|כל כותב אחר| A4["מפתח מתקפה"]
        A3 --> A5["המכשיר מאפיין אותו"]
        A4 --> A5
        A5 --> A6["מחזיק המפתח יכול לקרוא"]
    end
    subgraph AFTER["אחרי: מפתח חתום"]
        direction LR
        B2{"החתימה תקפה?"} -->|כן| B3["מפתח עובד מאומת"]
        B2 -->|לא| B4["דחה, נסה שוב"]
        B3 --> B5["רק עובד אמיתי קורא"]
    end
    A6 ~~~ B2
החומרה מגיעה מהשאלה מה המודל נושא. הארכיטקטורה הזו קיימת כדי לשמור בדיוק את הנתונים שהאנשים הכי מתנגדים לקריאה, והיא מצליחה בחצי הקשה יותר של הבעיה: עבודה משולמת לא ניתנת לפענוח על ידי אף אחד, כולל המפעיל. הפער נמצא בשלב אחד שבו המכשיר צריך לקבוע למי הוא מדבר.

הקריפטוגרפיה תקינה וההיכרות אינה מאומתת

המתקפה לא מפצלת כלום. X25519 ו-ML-KEM-768 פועלים בדיוק כפי שמוגדר. המתקפה מספקת מפתח והופכת לחלק לגיטימי של ההסכם.
זהו הסכם מפתח לא מאומת, ואופן הכישלון שלו הוא התוצאה הוותיקה ביותר בתחום. דיפי-הלמן פשוט לא מאמת אף אחד ונופל לחלק שמחליף את המפתח הציבורי שלו. מנגנוני קידוד מפתח יורשים את המאפיין, ולכן RFC 9180 מציב את האותנטיות של המפתח הציבורי של הנמען מחוץ לטווחו ומניח שהיישום הסביבתי יקים אותה דרך תעודות, ספריית מפתחות, או אימות מחוץ לרצועה. המודל הזה הוא היישום הסביבתי, והערוץ שבו הוא משתמש להפצת מפתח הנמען הוא הרכיב שמודל האמון שלו מסמן כלא מהימן.
ההגשה מתכננת מתקפה שכנה ומסגרת אותה:
הטענה היא write-once/first-wins כך שעובד מאוחר לא יכול לגנוב את החלפת המפתח של עבודה.
— §6, יישום מ参考
ההסבר הזה תקין והמנגנון עושה את מה שהוא אומר. מכסה אחת משני מקרים סימטריים.
איוםמטופל על ידי הטענה כתיבה-פעם-שנייה
עובד שני מחליף טענה קיימתכן — הכתיבה נדחתה
צד לא מורשה כותב את הטענה ראשוןלא — הכתיבה הראשונה מנצחת
First-wins הוא תחרות. הכלל מבטיח שהניצחון שומר את העבודה ואומר כלום על מי הניצחון הוא.
טענה נוספת שווה לציטוט, מכיוון שהגילוי סותר אותה:
אין מתווך (שער, תיאום, אחסון, מעקב) מעולם מחזיק חומר מפתח מספיק כדי להסיק סוד כלשהו. מתקפה שמפרת תיאום או אחסון מקבלת רק בולבים עוורים ומפתחות ציבוריים.
— §4.3, מפתחות עצמאיים לכיוון
המשפט הראשון מדויק. השני מתאר מתקפה שקוראת. מתקפה שמכתיבה מניחה מפתח ציבורי נבחר ברשומת הטענה לפני שההתקן משאל, והסקת הסוד המוסרי נעשית לא נחוצה עבור צד שיכול לסדר להיות הצד השני. מי ששולט בתוכן הרשומה שולט מי יכול לקרוא אתpayload, מה שהופך את שכבת התיאום לרכיב מהימן לסודיות — הדבר היחיד §3 אומר שאין רכיב מלבד ההתקן והעובד שצריך לעולם להיות.
גבול כנה לטענה: זה לא אומר שאף אחד באינטרנט הפתוח יכול לקרוא את הנתונים האלה היום. בפריסה אמיתית היכולת לכתוב טענות מאחורית רשת ענן ואישורים, והחשיפה מתארת שער אימות במסלול ההתקן. הבעיה המדויקת היא שסודיות כעת תלויה באותו פרימטר, בעוד הבטחת המרכז של הארכיטקטורה היא שהיא מחזיקה ללא אמון ברכיבים שבין ההתקן לעובד.

שתי תכונות עיצוב משלבות את ההשלכות

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

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

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

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

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

ייעוץ

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