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

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

הבעיה היא שהבלוקצ'יין עצמו הוא ישות אוטונומית וסגורה, ולכן החוזים החכמים בתוך הבלוקצ'יין אינם יודעים דבר על העולם החיצון. יחד עם זאת, תנאי החוזים החכמים קשורים לרוב למידע על דברים אמיתיים (עיכוב בטיסות, שערי חליפין וכו'). כדי שחוזים חכמים יפעלו כראוי, מידע המתקבל מחוץ לבלוקצ'יין חייב להיות אמין ומאומת. בעיה זו נפתרת על ידי שימוש באורקלים כגון Town Crier ו-DECO. אורקולים אלה מאפשרים לחוזה חכם ברשת הבלוקצ'יין לסמוך על מידע משרת אינטרנט מהימן; אנו יכולים לומר שמדובר בספקים של מידע אמין.

אורקל

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

בכל הנוגע למקור המידע, יכולים להיות 2 תרחישים: חיבור חוזה חכם לאתר מהימן שבו מידע על תוצאות התאמה מאוחסן באופן מרכזי, והאפשרות השנייה היא לחבר מספר אתרים בו זמנית ולאחר מכן לבחור מידע מרוב המקורות שמספקים את אותם נתונים. על מנת לוודא את נכונות המידע נעשה שימוש באורקלים, למשל Oraclize, המשתמשת ב-TLSNotary (שינוי נוטריוני TLS להוכחת האותנטיות של נתונים). אבל יש מספיק מידע בגוגל על ​​Oraclize, ויש כמה מאמרים על Habré, היום אדבר על אורקלים שמשתמשים בגישה קצת אחרת להעברת מידע: Town Crier ו-DECO. המאמר מספק תיאור של עקרונות הפעולה של שני האורקלים, כמו גם השוואה מפורטת.

בכיין העיר

Town Crier (TC) הוצג על ידי IC3 (היוזמה למטבעות קריפטו וחוזים) בשנת 2016 ב-CCS'16. הרעיון המרכזי של TC: העברת מידע מאתר לחוזה חכם ולוודא שהמידע שנמסר על ידי TC זהה לזה שבאתר. TC משתמש ב-TEE (סביבת ביצוע מהימנה) כדי לאמת בעלות על נתונים. הגרסה המקורית של TC מתארת ​​כיצד לעבוד עם Intel SGX.
Town Crier מורכב מחלק בתוך הבלוקצ'יין וחלק בתוך מערכת ההפעלה עצמה - TC Server.

חוזה TC נמצא ב-blockchain ומשמש כחזית הקצה של TC. הוא מקבל בקשות מה-CU (חוזה חכם משתמש) ומחזיר תגובה משרת ה-TC. בתוך ה-TC Server יש Relay, שיוצר חיבור בין המובלעת לאינטרנט (תעבורה דו-כיוונית) ומחבר את המובלעת עם הבלוקצ'יין. Enclave מכיל progencl, שזה קוד שמבצע בקשות מהבלוקצ'יין ומחזיר הודעות לבלוקצ'יין עם חתימה דיגיטלית, progencl מכיל חלק מקוד החוזה החכם ובעצם מבצע חלק מתפקידיו.

ניתן לחשוב על מובלעת SGX של אינטל כספרייה משותפת עם API הפועל באמצעות ecall. Ecall מעבירה את השליטה למובלעת. המובלעת מבצעת את הקוד שלה עד שהוא יוצא או עד שמתרחש חריג. ocall משמש לקריאת פונקציות המוגדרות מחוץ למובלעת. Ocall מבוצע מחוץ למובלעת ומתייחסים אליו כאל קריאה לא מהימנה על ידה. לאחר ביצוע ocall, השליטה מוחזרת למובלעת.

בחלק ה-Enclave, ערוץ מאובטח מוגדר עם שרת אינטרנט, המובלעת עצמה מבצעת לחיצת יד של TLS עם שרת היעד ומבצעת את כל פעולות ההצפנה באופן פנימי. ספריית TLS (mbedTLS) וקוד HTTP מופחת יוצאו לסביבת SGX. כמו כן, Enclave מכיל אישורי CA שורש (אוסף של אישורים) לאימות האישורים של שרתים מרוחקים. Request Handler מקבל בקשת Datagram בפורמט שמספק Ethereum, מפענח אותה ומנתח אותה. לאחר מכן הוא יוצר עסקת Ethereum המכילה את הנתונים המבוקש, חותם אותה עם skTC ומשדר אותה ל-Relay.

החלק הממסר כולל ממשק לקוח, TCP, ממשק בלוקצ'יין. יש צורך בממשק הלקוח כדי לאשר את קוד המובלעת ולתקשר עם הלקוח. הלקוח שולח בקשת אישור באמצעות ecall ומקבל חותמת זמן חתומה על ידי skTC יחד עם att (חתימת אישור), ואז att מאומת באמצעות Intel Attestation Service (IAS), וחותמת הזמן מאומתת על ידי שירות זמן מהימן. ממשק בלוקצ'יין מאמת בקשות נכנסות ומציב עסקאות בבלוקצ'יין לצורך מסירת דגימות נתונים. Geth הוא לקוח רשמי של Ethereum ומאפשר ל-Relay לקיים אינטראקציה עם הבלוקצ'יין באמצעות שיחות RPC.

עבודה עם TEE, TC מאפשרת לך להריץ מספר מובלעות במקביל, ובכך להגדיל את מהירות עיבוד המידע פי 3. אם במובלעת רצה אחת המהירות הייתה 15 tx/sek, אז עם 20 מובלעות ריצות מקבילות המהירות עולה ל-65 tx/sec; לשם השוואה, מהירות הפעולה המקסימלית בבלוקצ'יין הביטקוין היא 26 tx/sec.

דקו

DECO (Decentralized Oracles for TLS) הוצג ב-CCS'20, עובד עם אתרים התומכים בחיבורי TLS. מבטיח סודיות ויושרה של הנתונים.
DECO עם TLS משתמש בהצפנה סימטרית, כך שללקוח ולשרת האינטרנט יש מפתחות הצפנה, והלקוח יכול לזייף נתוני הפעלה של TLS אם הוא רוצה. כדי לפתור בעיה זו, DECO משתמש בפרוטוקול לחיצת יד תלת כיוונית בין המוכיח (חוזה חכם), המאמת (אורקל) ושרת האינטרנט (מקור הנתונים).

הדרך בה DECO פועלת היא שהמאמת מקבל נתון D ומאשר למאמת ש-D הגיע משרת ה-TLS S. בעיה נוספת היא ש-TLS לא חותם על הנתונים וקשה ללקוח ה-TLS להוכיח ש- הנתונים התקבלו בדיוק מהשרת הנכון (קושי מוצא).

פרוטוקול DECO משתמש במפתחות הצפנה KEnc ו-KMac. הלקוח שולח בקשה Q אל שרת אינטרנטהתגובה משרת R מגיעה מוצפנת, אך הלקוח והשרת חולקים את אותו KMac, והלקוח יכול לזייף את הודעת ה-TLS. הפתרון של DECO הוא "להסתיר" את ה-KMac מהלקוח (המאמת) עד שהוא מגיב לבקשה. כעת ה-KMac מחולק בין המאמת למאמת - KpMac ו-KvMac. השרת מקבל את ה-KMac כדי להצפין את התגובה באמצעות פעולת חלוקת המפתחות KpMac ⊕ KvMac = KMac.

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

כשמדברים על מערכת אורקל מבוזרת, אי אפשר שלא להזכיר את Chainlink, שמטרתה ליצור רשת מבוזרת של צמתים אורקל התואמים עם Ethereum, Bitcoin ו-Hyperledger, תוך התחשבות במודולריות: ניתן לעדכן כל חלק במערכת. במקביל, כדי להבטיח אבטחה, Chainlink מציעה לכל אורקל שמשתתף במשימה להנפיק שילוב של מפתחות (ציבורי ופרטי). המפתח הפרטי משמש ליצירת חתימה חלקית המכילה את החלטתם לבקשת הנתונים. כדי לקבל תשובה, יש צורך לשלב את כל החתימות החלקיות של האורקלים של הרשת.

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

התקפות על אורקלים

מנקודת מבט של אבטחת מידע, נשקלו ההתקפות הבאות על Town Crier:

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

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

3. התקפות ערוץ צדדי.
   סוג מיוחד של התקפה המשתמש בניטור של זיכרון מובלעת וגישה למטמון בתרחישים שונים. דוגמה למתקפה כזו היא Prime and Probe.
   
   סדר תקיפה:

   • t0: התוקף ממלא את כל מטמון הנתונים של תהליך הקורבן.
   • t1: הקורבן מבצע קוד עם גישה לזיכרון התלויה בנתונים הרגישים של הקורבן (מפתחות קריפטוגרפיים). שורת המטמון נבחרת על סמך ערך keybit. בדוגמה באיור, keybit = 0 ונקראת הכתובת X בשורה 2 של המטמון. הנתונים המאוחסנים ב-X נטענים לתוך המטמון, מחליפים את הנתונים שהיו שם קודם.
   • t2: התוקף בודק אילו משורות המטמון שלו פונו - קווים המשמשים את הקורבן. זה נעשה על ידי מדידת זמן גישה. על ידי חזרה על פעולה זו עבור כל keybit, התוקף משיג את המפתח כולו.

הגנת תקיפה: לאינטל SGX יש הגנה מפני התקפות ערוץ צדדי המונעת ניטור של אירועים הקשורים למטמון, אך התקפת Prime ו-Probe עדיין תעבוד מכיוון שהתוקף עוקב אחר אירועי המטמון של התהליך שלו ומשתף את המטמון עם הקורבן.

לפיכך, כרגע אין הגנה אמינה מפני התקפה זו.

ידועות גם התקפות כמו Spectre ו-Foreshadow (L1TF), בדומה ל-Prime ו-Probe. הם מאפשרים לך לקרוא נתונים מזיכרון המטמון דרך ערוץ של צד שלישי. ניתנת הגנה מפני הפגיעות Spectre-v2, שפועלת נגד שתיים מהתקפות אלו.

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

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

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

השוואה בין אורקלים

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

בכיין העיר
דקו

ביצועים
מהיר יותר (0.6 שניות לסיום)
איטי יותר (10.50 שניות לסיום הפרוטוקול)

אבטחה
פחות מאובטח
יותר בטוח

עלות
יקר יותר
יותר זול

מעשיות
דורש חומרה מיוחדת
עובד עם כל שרת שתומך ב-TLS

ביצועים: כדי לעבוד עם DECO, נדרשת לחיצת יד תלת כיוונית, בעת הגדרה דרך LAN זה לוקח 0.37 שניות, לאינטראקציה לאחר יצירת החיבור, 2PC-HMAC יעיל (0,13 שניות לכתיבה). הביצועים של DECO תלויים בחבילות הצופן הזמינות של TLS, בגודל הנתונים הפרטיים ובמורכבות ההוכחות עבור יישום מסוים. שימוש באפליקציית האופציה הבינארית מ-IC3 כדוגמה: השלמת הפרוטוקול דרך LAN אורכת כ-10,50 שניות. לשם השוואה, ל-Town Crier לוקח בערך 0,6 שניות להשלים יישום דומה, שהוא מהיר פי 20 בערך מ-DECO. כשכל הדברים שווים, TC יהיה מהיר יותר.

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

עלות: עלות הציוד התומך ב-Intel SGX גבוהה מהעלות של הגדרת הפרוטוקול ב-DECO. לכן TC יקר יותר.

מעשיות: כדי לעבוד עם Town Crier, נדרש ציוד מיוחד התומך ב-TEE. לדוגמה, Intel SGX נתמך על דור 6 של מעבדי Intel Core ואילך. DECO מאפשר לך לעבוד עם כל ציוד, למרות שקיימת הגדרת DECO באמצעות TEE. לפי תהליך ההגדרה, לחיצת היד התלת-כיוונית של DECO עשויה לקחת קצת זמן, אבל זה כלום לעומת מגבלת החומרה של TC, כך ש-DECO יותר פרקטי.

מסקנה

כשמסתכלים על שני האורקלים בנפרד ומשווים אותם לפי ארבעה קריטריונים, ברור ש-Town Crier נחות מ-DECO בשלוש מתוך ארבע נקודות. DECO אמין יותר מבחינה אבטחת מידע, זול ומעשי יותר, למרות שהקמת פרוטוקול של שלושה צדדים עשויה לקחת קצת זמן ויש לה חסרונות, למשל פעולות נוספות עם מפתחות הצפנה. TC מהיר יותר מ-DECO, אך פגיעויות התקפות בערוץ צדדי הופכות אותו לרגיש לאובדן סודיות. יש לקחת בחשבון ש-DECO הוצג בינואר 2020, ולא חלף מספיק זמן כדי לראות בו בטוח. Town Crier מותקף כבר 4 שנים ועבר בדיקות רבות, כך שהשימוש בו בפרויקטים רבים מוצדק.

מקור: www.habr.com