DPKI: ביטול החסרונות של PKI ריכוזי באמצעות בלוקצ'יין

זה לא סוד שאחד מכלי העזר הנפוצים, שבלעדיהם בלתי אפשרי הגנה על נתונים ברשתות פתוחות, הוא טכנולוגיית האישורים הדיגיטליים. עם זאת, אין זה סוד שהחסרון העיקרי של הטכנולוגיה הוא אמון בלתי מותנה במרכזים המנפיקים תעודות דיגיטליות. מנהל הטכנולוגיה והחדשנות ב-ENCRY אנדריי Chmora הציע גישה חדשה לארגון תשתית מפתח ציבורי (תשתית מפתח ציבורי, PKI), אשר יסייע בביטול החסרונות הנוכחיים ואשר משתמש בטכנולוגיית ספר חשבונות מבוזר (בלוקצ'יין). אבל דבר ראשון.

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

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

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

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

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

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

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

הערה: האותנטיות והשלמות של המפתח הציבורי מאושרות בדיוק באותו אופן כמו האותנטיות והשלמות של נתונים ציבוריים, כלומר באמצעות חתימה דיגיטלית אלקטרונית (EDS).
מאיפה מגיעות תעודות דיגיטליות?רשויות אישורים מהימנות, או רשויות אישורים (CAs), אחראיות על הנפקה ותחזוקה של אישורים דיגיטליים. הפונה מבקש הוצאת אישור מה-CA, עובר זיהוי במרכז הרישום (CR) ומקבל אישור מה-CA. ה-CA מבטיח שהמפתח הציבורי מהאישור שייך בדיוק לישות שעבורה הוא הונפק.

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

תעודות דיגיטליות משמשות בכל מקום שקיים קריפטוגרפיה אסימטרית. אחת התעודות הדיגיטליות הנפוצות ביותר היא תעודות SSL לתקשורת מאובטחת על גבי פרוטוקול HTTPS. מאות חברות הרשומות בתחומי שיפוט שונים מעורבות בהנפקת תעודות SSL. המניה העיקרית נופלת על חמישה עד עשרה מרכזים מהימנים גדולים: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA ו-CR הם רכיבים של PKI, הכוללים גם:

• פתח את הספרייה – מאגר מידע ציבורי המספק אחסון מאובטח של תעודות דיגיטליות.
• רשימת התעודות שבוטלו – מסד נתונים ציבורי המספק אחסון מאובטח של תעודות דיגיטליות של מפתחות ציבוריים שנשללו (לדוגמה, עקב פגיעה במפתח פרטי מזווג). נושאי תשתית יכולים לגשת באופן עצמאי למסד נתונים זה, או שהם יכולים להשתמש בפרוטוקול הסמכה המקוון המיוחד (OCSP), אשר מפשט את תהליך האימות.
• משתמשי תעודה - נותנים שירות לנבדקי PKI שהתקשרו בהסכם משתמש עם ה-CA ומאמתים את החתימה הדיגיטלית ו/או הצפינו נתונים על סמך המפתח הציבורי מהאישור.
• עוקבים - שירת נבדקי PKI שבבעלותם מפתח סודי המזוהה עם המפתח הציבורי מהאישור, ואשר התקשרו בהסכם מנוי עם ה-CA. המנוי יכול להיות בו זמנית משתמש בתעודה.

לפיכך, ישויות מהימנות של תשתית המפתח הציבורי, הכוללות CAs, CRs וספריות פתוחות, אחראיות על:

1. אימות האותנטיות של זהות המבקש.
2. יצירת פרופיל של תעודת המפתח הציבורי.
3. הנפקת תעודת מפתח ציבורי למבקש שזהותו אושרה באופן מהימן.
4. שנה את המצב של אישור המפתח הציבורי.
5. מתן מידע על המצב הנוכחי של תעודת המפתח הציבורי.

החסרונות של PKI, מה הם?הפגם הבסיסי של PKI הוא נוכחותם של ישויות מהימנות.
המשתמשים חייבים לתת אמון ללא תנאי ב-CA וב-CR. אבל, כפי שמראה בפועל, אמון ללא תנאי טומן בחובו השלכות חמורות.

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

- בשנת 2010, התוכנה הזדונית של Stuxnet החלה להתפשט באינטרנט, חתומה באמצעות תעודות דיגיטליות גנובות מ-RealTek ו-JMicron.

- בשנת 2017, גוגל האשימה את סימנטק בהנפקת מספר רב של אישורים מזויפים. באותה תקופה, סימנטק הייתה אחת ה-CAs הגדולות ביותר במונחים של כמויות ייצור. בדפדפן Google Chrome 70 הופסקה התמיכה בתעודות שהונפקו על ידי חברה זו והמרכזים המסונפים לה GeoTrust ו-Thawte לפני 1 בדצמבר 2017.

ה-CAs נפגעו, וכתוצאה מכך כולם סבלו - ה-CAs עצמם, כמו גם המשתמשים והמנויים. האמון בתשתיות התערער. בנוסף, תעודות דיגיטליות עלולות להיחסם בהקשר של סכסוכים פוליטיים, מה שישפיע גם על פעולתם של משאבים רבים. זה בדיוק מה שחששו לפני מספר שנים בממשל הנשיאותי הרוסי, שבו ב-2016 דנו באפשרות ליצור מרכז הסמכה ממלכתי שינפיק תעודות SSL לאתרים ברשת RuNet. מצב העניינים הנוכחי הוא כזה שאפילו פורטלי המדינה ברוסיה שימוש תעודות דיגיטליות שהונפקו על ידי חברות אמריקאיות Comodo או Thawte (חברה בת של סימנטק).

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

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

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

ביזור אינו מרמז על נוכחות של ישויות מהימנות - אם אתה יוצר תשתית מפתח ציבורי מבוזרת (תשתית מפתח ציבורי מבוזר, DPKI), אז אין צורך ב-CA או ב-CR. בואו נטוש את הרעיון של תעודה דיגיטלית ונשתמש ברישום מבוזר כדי לאחסן מידע על מפתחות ציבוריים. במקרה שלנו, אנו קוראים לרישום בסיס נתונים ליניארי המורכב מרשומות בודדות (בלוקים) המקושרים באמצעות טכנולוגיית בלוקצ'יין. במקום תעודה דיגיטלית, נציג את המושג "הודעה".

כיצד ייראה תהליך קבלת, אימות וביטול הודעות ב-DPKI המוצע:

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

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

3. אימות האותנטיות של זהותו של הפונה מתבצע לאחר מעשה על ידי מאמצים משותפים של קהילת המשתמשים של DPKI, ולא על ידי CR.

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

5. כל אחד יכול לגשת לפנקס החשבונות המבוזר ולבדוק את המצב הנוכחי של המפתח הציבורי.

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

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

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

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

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

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

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

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

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

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

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

בואו נבהיר שוב את מטרת המפתחות:

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

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

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

כל העסקאות העוקבות אחר האפס נוצרות בצורה דומה: המפתח הציבורי (לא הארנק, כמו במקרה של עסקת האפס, אלא מזוג מפתחות רגיל) מתנהל דרך שתי פונקציות Hash SHA256 ו-RIPEMD160. כך נוצרים הנתונים של השדה השלישי. השדה הרביעי מכיל מידע נלווה (לדוגמה, מידע על המצב הנוכחי, תאריכי תפוגה, חותמת זמן, מזהים של אלגוריתמי קריפטו בשימוש וכו'). השדה החמישי מכיל את המפתח הציבורי מצמד מפתחות השירות. בעזרתו, החתימה הדיגיטלית תיבדק אז, כך שהיא תשוכפל. הבה נצדיק את הצורך בגישה כזו.

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

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

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

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

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

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

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

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

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

בואו נדמיין שצריך לבדוק האם עסקה מס' 3 אכן מגיעה אחרי עסקה מס' 2. לשם כך, באמצעות שיטת הגיבוב המשולבת, ערך פונקציית הגיבוב מחושב עבור הנתונים מהשדה השלישי, הרביעי והחמישי של עסקה מס' 2. לאחר מכן מתבצע שרשור הנתונים מהשדה הראשון של עסקה מס' 3 וערך פונקציית ה-hash המשולב שהושג קודם לכן עבור נתונים מהשדה השלישי, הרביעי והחמישי של עסקה מס' 2. כל זה מתנהל גם באמצעות שתי פונקציות Hash SHA256 ו-RIPEMD160. אם הערך שהתקבל תואם את הנתונים בשדה השני של עסקה מס' 2, אזי הבדיקה מועברת והחיבור מאושר. זה מוצג בצורה ברורה יותר באיורים שלהלן.

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

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

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

1. רישום הודעות תקפות (RDN).
2. רישום הודעות שבוטלו (RON).
3. רישום הודעות מושעות (RPN).

מידע על מפתחות ציבוריים מאוחסן ב-RDN/RON/RPN בצורה של ערכי hash. כמו כן, ראוי לציין כי אלה יכולים להיות או רישום שונים, או רשתות שונות, או אפילו שרשרת אחת כחלק ממרשם יחיד, כאשר מידע על מצבו של מפתח ציבורי רגיל (שלילה, השעיה וכו') מוכנס ל- שדה רביעי של מבנה הנתונים בצורה של ערך הקוד המתאים. ישנן אפשרויות רבות ושונות ליישום הארכיטקטוני של DPKI, והבחירה באחד או באחר תלויה במספר גורמים, למשל, קריטריוני אופטימיזציה כגון עלות הזיכרון לטווח ארוך לאחסון מפתחות ציבוריים וכו'.

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

נותרה השאלה העיקרית - איזה רישום מתאים להטמעת הטכנולוגיה?

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

אנו ב-ENCRY ניסינו לפתור את הבעיות שנוסחו לעיל ופיתחנו רישום, שלדעתנו יש לו מספר יתרונות, כלומר:

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

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

1. הפונה נרשם ב-DPKI ומקבל ארנק דיגיטלי. כתובת הארנק היא ערך הגיבוב של המפתח הציבורי של הארנק. המפתח הפרטי של הארנק ידוע רק למבקש.
2. לנושא הרשום ניתנת גישה למפתח הסודי של השירות.
3. הנבדק יוצר עסקת אפס ומאמת אותה בחתימה דיגיטלית באמצעות המפתח הסודי של הארנק.
4. אם נוצרת עסקה שאינה אפס, היא מאושרת על ידי חתימה דיגיטלית אלקטרונית באמצעות שני מפתחות סודיים: ארנק ושירות אחד.
5. הנבדק מגיש עסקה למאגר.
6. צומת הרשת ENCRY קורא את העסקה מהמאגר ובודק את החתימה הדיגיטלית, כמו גם את הקישוריות של העסקה.
7. אם החתימה הדיגיטלית תקפה והחיבור אושר, אזי היא מכינה את העסקה לכניסה למרשם.

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

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

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

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

מקור: www.habr.com