דפדפן יכול להפעיל קריפטוגרפיה חזקה; עדיין צריך לתת אמון בקוד שמסופק לדפדפן.
דפדפן יכול לבצע הצפנה מקצה לקצה באופן מקומי, לרבות הקמת מפתחות פוסט־קוונטית, בלי להתקין יישום הודעות מקורי. השאלה הקשה אינה אם המתמטיקה יכולה לפעול בלשונית. היא אם היישום המסופק, הטיפול במפתחות ונתיב העדכון ראויים לאמון שהשיחה דורשת.
גישה דרך הרשת יכולה להיות נוחה כשאי אפשר להתקין. היא אינה הופכת את היישום לחסין מצנזורה, משירות אירוח שנפרץ, מהרחבות זדוניות או ממכשיר שנפרץ.
אבני הבניין הקריפטוגרפיות של הדפדפן
WebCrypto חושף פעולות ברמה נמוכה להצפנה, לגזירת מפתחות, לחתימה ולניהול מפתחות. מימושים נפוצים מספקים פרימיטיבים כגון AES-GCM ו־ECDH. הפעולות האלה הן אבני בניין, לא פרוטוקול מלא ומאומת להעברת הודעות.
יישום רשת יכול להוסיף מימוש ML-KEM שעבר סקירה באמצעות JavaScript או WebAssembly במקום שבו ה־API המובנה הדרוש אינו זמין. תמיכת הדפדפנים משתנה, ולכן מפתחים צריכים לבדוק את זמינות היכולות בגרסאות היעד המדויקות, במקום להניח שכל דפדפן מציע אותם אלגוריתמים.
תהליך היברידי רעיוני הוא:
- יצירת מפתחות מתאימים באמצעות אקראיות בטוחה קריפטוגרפית.
- אימות חומר המפתחות של הצד השני באמצעות מנגנון הזהות של הפרוטוקול.
- קבלת תרומות קלאסיות ופוסט־קוונטיות לסוד משותף.
- שילובן לפי תהליך גזירת המפתחות המוגדר ובהקשר השיחה.
- שימוש במפתחות שנגזרו להצפנה מאומתת, תוך טיפול נכון ב־nonce ובמצב.
זהו מתווה הסברי, לא מתכון למימוש. FIPS 203 מגדיר תקן ל־ML-KEM; הוא אינו מסמיך יישום דפדפן מסוים ואינו מגדיר כל שלב בפרוטוקול צ'אט.
אספקה דרך HTTPS היא חלק ממודל האמון
השרת בדרך כלל מספק את ה־JavaScript ואת ה־WebAssembly שיעבדו את הטקסט הגלוי. יישום ששונה בזדון יכול לקרוא הודעה לפני ההצפנה או אחרי הפענוח, גם אם הספרייה הקריפטוגרפית שלו משתמשת באלגוריתמים תקינים.
HTTPS מסייע לאמת את האספקה ולהגן עליה מהתערבות ברשת. הוא אינו מוכיח שמפעיל המקור, מערכת הפריסה שלו או התלויות שלו לא נפרצו. דף HTTPS רגיל אינו הופך אוטומטית לחבילת יישום שנחתמה באופן עצמאי.
שיקולי האבטחה של W3C ל־WebCrypto דנים בהזרקת סקריפטים ובצורך להגן על שלמות היישום. מדיניות אבטחת תוכן, ניהול קפדני של תלויות ובקרות אבטחת רשת אחרות מצמצמים סיכונים, אך אף אחד מהם אינו הופך סקריפט שרירותי מאותו מקור לצופה בלתי מהימן שאינו יכול לגעת בנתוני היישום.
גם WebAssembly חולק את גבול האבטחה של היישום. ארגז החול שלו מגביל גישה למארח דרך ממשקים מוגדרים; הוא אינו הופך את הדף הקורא למהימן. הידור C ל־Wasm אינו הופך את שפת המקור לבטוחה מבחינת זיכרון.
מפתחות אינם בהכרח קיימים רק ב־RAM
יישום הודעות בדפדפן עשוי לשמור מפתחות או מצב מוצפן באופן מתמשך, כדי שהמשתמש יוכל לחזור לאותה זהות. הוא עשוי גם להציע קישור מכשירים או שחזור מוצפן. יש לתעד את ההתנהגויות האלה, במקום להניח שאינן קיימות.
שאלות שכדאי לשאול כוללות:
- אילו מפתחות נשמרים באופן מתמשך, ובאיזה אחסון בדפדפן?
- מה קורה כשמנקים את נתוני האתר או כשמסתיים סשן גלישה פרטית?
- האם קוד זדוני שפועל בהקשר היישום עדיין יכול להשתמש במפתח שאינו ניתן לחילוץ?
- האם עדכון שסופק זה עתה יכול לגשת למצב מקומי ישן?
- האם השחזור מחזיר זהות, היסטוריית הודעות או את שתיהן?
מפתח WebCrypto שאינו ניתן לחילוץ מגביל ייצוא דרך ה־API. כשלעצמו, הוא אינו מונע מקוד עוין של היישום לבקש פעולות מותרות או לאסוף טקסט גלוי.
ללקוחות רשת וללקוחות מקוריים יש פשרות שונות
| נושא | לקוח בדפדפן | לקוח מקורי |
|---|---|---|
| הפצה | המקור, האירוח ושרשרת עדכוני הרשת | חנות יישומים או הפצת חבילות ושרשרת החתימה |
| שמירה מקומית | אחסון בדפדפן והתנהגות הפרופיל | אחסון היישום במערכת ההפעלה ומחזור חיי היישום |
| חשיפה | סקריפטים מאותו מקור, הרחבות וחולשות בדפדפן | תלויות היישום וחולשות במערכת ההפעלה וביישום |
| זמינות | דומיין נגיש ושירותי הרשת הנדרשים | יישום מותקן עדיין זקוק לשירותי הרשת הנדרשים לו |
אף עמודה אינה קובעת מנצח בלי לבחון את המימוש. יישום רשת עשוי להישאר נגיש לאחר הסרה מחנות יישומים, אבל דומיין חסום או נתיב רשת חסר עדיין יכולים למנוע גישה.
מדדו ביצועים במקום להבטיח אותם
לפי FIPS 203, ML-KEM-768 משתמש במפתח כימוס בגודל 1,184 בתים ובטקסט מוצפן בגודל 1,088 בתים. הגדלים האלה עוזרים להסביר מדוע פרוטוקולים עשויים לתזמן עדכוני KEM במקום לצרף חומר חדש לכל הודעה קצרה. הם אינם מדידות של רוחב הפס או המהירות של יישום שלם.
מבחן ביצועים מועיל מציין את הדפדפן, המכשיר, גרסת הבנייה, שיטת החימום, הפעולה שנמדדת והתפלגות הזמנים. יש לכלול את הפעלת הדף, טעינת המודולים, השימוש בזיכרון, מכשירים חלשים ותקורת הרשת. טענות כגון ״פחות משתי אלפיות שנייה בכל הטלפונים המודרניים״ דורשות מדידות שפורסמו; מאמר זה אינו מספק אותן.
החלת הדברים על Livara
סקירת האבטחה של Livara מתעדת את LVR1 ואת גבולות השחזור שלו. Proof Lab מדגים פעולות מקומיות נבחרות של P-256, HKDF ו־AES-GCM; הדף מציב במפורש את ההרכבה המלאה של LVR1/LGS1 מחוץ לתחום הבדיקה הזו. לכן הדגמה מוצלחת אינה מוכיחה את האבטחה של כל קוד הרשת שמופץ.
לפני שיחה רגישה בדפדפן, השתמשו בלקוח אותנטי ומתוחזק, עיינו במודל האיומים העדכני, הגנו על פרופיל הדפדפן ואמתו את הצד השני באמצעות תהליך בדיקת המפתחות הנתמך. נוחות וקריפטוגרפיה מועילה יכולות להתקיים יחד, כל עוד גבול האספקה דרך הרשת נשאר חלק מההערכה.
