חלק 3: בראשית של שחזור חשבונות - הימנעות משיתוף פעולה והדלפות | פִּנקָס

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

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

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

שכבות אבטחה מרובות

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

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

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

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

איך Ledger Recover עושה את זה: חומרה מאובטחת ורמות הצפנה מרובות

ב- Ledger Recover, המסופקת על ידי Coincover, אנו משתמשים במאפיינים של החומרה המאובטחת העומדת לרשותנו כדי לענות על שאלות אלו בצורה הידידותית ביותר למשתמש. אנו מסתמכים על הרכיב המאובטח (SE) הכלול בארנק החומרה של Ledger שלך, כמו גם על מודולי אבטחת חומרה (HSM) המשמשים כל אחד מספקי הגיבוי.

אלמנטים מאובטחים: כוחה של אבטחה בכף היד שלך

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

Ledger Nano שלך מסתמך על טכנולוגיה מוכחת ואמינה זו כדי לאחסן ולהגן על הזרע שלך. מערכת ההפעלה Ledger הפועלת ב-SE זה תמיד תבקש את הסכמתך הפיזית לפני השימוש ב-Seed.

HSMs: אבטחת השרתים

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

Ledger משתמש במספר HSMs עבור מקרי שימוש שונים, כולל אימות האותנטיות של מכשירי Ledger Nano ו- Ledger Stax, ואפשר עדכוני מערכת הפעלה מאובטחים בערוץ מוצפן ומאומת.

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

הצפנת זרע על ידי ה-Secure Element

שכבת ההגנה הראשונה מגיעה מה-Secure Element (SE) עצמו. לפני פיצול האנטרופיה לשלושה שיתופים, ה-SE מצפין אותה באמצעות מפתח סימטרי AES 256 המאוחסן במערכת ההפעלה שלו (המכונה 'מפתח הצפנת אנטרופיה'). לאחר ההצפנה, האנטרופיה מחולקת לשלושה שיתופים שמופצים לאחר מכן לספקי גיבוי. כמובן, יש לך שליטה על התהליך הזה, וה-SE תמיד יבקש את הסכמתך המפורשת לפני שתתחיל אותו, בדיוק כמו עבור כל אפליקציה אחרת המבקשת גישה ל-seed.

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

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

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

הגנה על מפתח הצפנת האנטרופיה

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

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

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

שתף הצפנה במנוחה עבור ספקי גיבוי

עכשיו בצד של ספקי הגיבוי, יש לנו הגדרה קצת שווה.

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

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

השיתופים אף פעם לא משאירים את גבולות ה-HSM ברורים, והם תמיד מוצפנים במעבר או במצב מנוחה.

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

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

HSMs Strike Again: גיוון מסדי נתונים

אוקיי, אנחנו מתקרבים לפתרון מלא לאחסון מאובטח של המניות שלנו!

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

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

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

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

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

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

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

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

בטוח ונעים, עכשיו כדי להוכיח שאני אני

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

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

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

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

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

פייר AOUN / Yacine BADISS

אדריכלי תוכנה

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• PlatoData.Network Vertical Generative Ai. העצים את עצמך. גישה כאן.
• PlatoAiStream. Web3 Intelligence. הידע מוגבר. גישה כאן.
• PlatoESG. רכב / רכבים חשמליים, פחמן, קלינטק, אנרגיה, סביבה, שמש, ניהול פסולת. גישה כאן.
• PlatoHealth. מודיעין ביוטכנולוגיה וניסויים קליניים. גישה כאן.
• ChartPrime. הרם את משחק המסחר שלך עם ChartPrime. גישה כאן.
• BlockOffsets. מודרניזציה של בעלות על קיזוז סביבתי. גישה כאן.
• מקור: https://www.ledger.com/blog/part-3-genesis-of-ledger-recover-avoiding-collusion-and-leaks