חוות דעת מאת אנדריאס פרוינד, חבר בקבוצת האינטרסים של Mainnet EEA
לבלוקצ'יין יש בעיה שדובר עליה רק לעתים רחוקות, שאינה תלויה בעליות ומורדות של שווקי הקריפטו, ואשר יכולה להפריע לאימוץ בלוקצ'יין לטווח ארוך יותר מחוץ למקרי שימוש ישיר לצרכן וכמה מקרי שימוש B2B: אלגוריתמי הצפנה של בלוקצ'יין אינם תואמים ל-NIST. גורם מרכזי בהשגת ציות ל-FISMA (חוק ניהול אבטחת מידע פדרלי)! ותאימות ל-NIST/FISMA, או המקבילה לכך מחוץ לארה"ב, היא דבר גדול כאשר ארגונים מתמודדים עם ממשלות או ארגונים המתמודדים באופן קבוע עם ארגונים המתמודדים עם ממשלות.
מדוע בלוקצ'יין בדרך כלל אינם תואמים ל-NIST? ובכן, הסיבה העיקרית היא ש-Blockchains נולדו מתוך חוסר אמון עמוק בכל מה שמופעל ואושר על ידי הממשלה בעקבות המיתון הגדול של 2008; כולל אלגוריתמים קריפטוגרפיים שאושרו על ידי הממשלה. בכל מקרה, אלגוריתם הגיבוב SHA-3 המקובל כיום לא הושלם עד 2015 לאחר ש-Blockchains כגון Ethereum כבר עשו את הבחירות שלהם לגבי אלגוריתמי גיבוב. לכן, רוב הבלוקצ'יין כגון Ethereum משתמשים באלגוריתמים שלא רק שאינם מאושרים על ידי NIST, אלא ש-NIST ממליצה לא להשתמש בהם. שימו לב, ישנם Blockchains תואמי NIST כגון Simba-Chain או Fabric הפועלים על LinuxONE של יבמ. עם זאת, עלותם גבוהה וקשה לניהול בייצור[1] כפי שלמדו ארגונים לאחר שהוציאו כמה עשרות מיליוני דולרים על דמי ייעוץ ויישום. מה שמחריף את בעיית העלויות היא שלעתים קרובות הם אינם מניבים את התוצאות העסקיות הצפויות מכיוון שמקרי השימוש שנבחרו לא התאימו ל-Blockchain מלכתחילה! הפתרון העיקרי לדיון שלהלן הוא שכל גישת בלוקצ'יין ארגונית חדשה חייבת להתייחס לא רק לציות ל-NIST, אלא גם הן לעלות והן למורכבות הניהול ביעילות כדי למשוך ספונסרים עסקיים חדשים.
האם זה אומר שהכל חסר סיכוי עבור Blockchain בארגון כאשר תאימות NIST, עלות ומורכבות ניהול מהווים דאגה?
למרבה המזל, התשובה היא לא, זה לא חסר סיכוי. לא טריוויאלי, אבל לא חסר תקווה.
כדי להבין מה זה אומר, בואו נסכם מהם המאפיינים של יישומים מבוססי בלוקצ'יין יכול has you
- שלמות הנתונים: אם אתה רק צריך את זה, אל תשתמש ב- Blockchain. יש חלופות זולות יותר.
- חותמת זמן הניתנת להוכחה: הרבה יותר מעניין ושימושי עבור מסלולי ביקורת, למשל על פני שרשראות אספקה.
- אין נקודת כשל בודדת: אם אתה צריך 100% זמינות, במחיר נמוך.
- התנגדות לצנזורה: גישה לנתונים שצריכים לבחון למשל צדדים שלישיים שאינם בהכרח מזוהים בזמן יצירת הנתונים, או ביצוע (בעצם) עסקאות בלתי הפיכות ללא תלות בצד שלישי כלשהו.
- הגנה כפולה: רלוונטי רק אם אתה עוסק בנכסים דיגיטליים ב- Blockchain. במילים אחרות, אתה באמת אוהב DeFi.
- הורשת ערבויות אבטחה בלוקצ'יין: זה מעניין מאוד, אם אתה צריך מדרגיות של יישומים, אך עם זאת אבטחה גבוהה. עוד מעט נגיע לזה.
שימו לב שאף אחד מהאמור לעיל אינו מדבר על פרטיות נתונים, אחד התכשיטים היקרים ביותר של דרישות יישומים ארגוניים. אבל אל דאגה, אתה יכול להשיג פרטיות נתונים מבלי להדביק נתונים רגישים לעסקים בכל מקום בשטח פתוח. גם לזה עוד מעט נגיע.
לפני שנקדים את עצמנו, בואו נעצור כאן ונדון כיצד המאפיינים הללו קשורים לתאימות ל-NIST. במבט ראשון, לא כל כך, אבל בואו נעבור על כל מאפיין ונדון בהשלכותיו ביתר פירוט. עם זאת, ראשית, ראוי להזכיר שכדי לקבל הרשאות Authority-To-Operate (ATO) מממשלה, למשל ממשלת ארה"ב[2], זה בסדר להשתמש באלגוריתמים קריפטוגרפיים שאינם תואמים ל-NIST, או באלגוריתמים ש-NIST לא גיבשה דעה לגביהם, כל עוד האלגוריתמים הללו אינם בסיסיים לאבטחת האפליקציה ולפרטיות הנתונים שלה. לדוגמה, עליך להוכיח שחוזה בוצע ביום מסוים ומאז לא השתנה. באמצעות בלוקצ'יין, אפשר ליצור טביעת אצבע קריפטוגרפית תוך שימוש ב-hash קריפטוגרפי (מאושר על ידי NIST) של החוזה, ולאחר מכן מעגן את ה-hash הזה ב-Blockchain (ציבורי) המספק, ברגע שהוא נכלל בבלוק, חותמת זמן הניתנת להוכחה באמצעות השילוב של מספר בלוק, גיבוב חסום וחותמת זמן. אם הבלוקצ'יין היה מאורגן מחדש, למשל באמצעות התקפה של 51%, עדיין ניתן היה לקחת את העסקה עם ה-hash של החוזה, והחסימה שלו ולכלול את שניהם בבלוקצ'יין אחר (ציבורי). לכן, האבטחה של הבלוקצ'יין המקורי (הציבורי) אינה בסיסית למקרה השימוש.
עם זאת בחשבון, הבה נסתכל שוב על כל מאפיין, תוך התמקדות בהשפעתו על תאימות NIST של יישום המשתמש בטכנולוגיית Blockchain:
- שלמות הנתונים: זה קל מכיוון שתמיד אתה יכול לקבל עותק של הנתונים הרלוונטיים שעיגנת, למשל באמצעות hash קריפטוגרפי ב-Blockchain עם צורה אחרת של הגנה על שלמות נתונים, כגון אישור W3C Verifiable Credential מובהק עם אלגוריתם חתימה קריפטוגרפית שאושר על ידי NIST .
- חותמת זמן הניתנת להוכחה: קצת יותר קשה אבל בר ביצוע. אם השרשרת המנוצלת נפגעת, עדיין ניתן היה לתפוס את הבלוק עם העסקה הרלוונטית המכילה למשל חשיב קריפטוגרפי תואם NIST של מסמך, וחותמת הזמן שלו, ולעגן את כל הבלוק עם העסקה דרך Hash קריפטוגרפי אחר תואם NIST בבלוקצ'יין אחר; לא נגרם נזק אמיתי.
- אין נקודת כשל בודדת: אוקיי, אז זה קצת מסובך מכיוון ש-NIST לא יצרה המלצות על אלגוריתמי קונצנזוס. כלומר כל עוד למודל הקונצנזוס יש בסיס אקדמי מוצק, למשל הוכחה מתמטית לאבטחה, אפשר לטעון עליו בהצלחה, ואנחנו שמים אותו בדלי שאינו תואם ל-NIST.
- התנגדות לצנזורה: זה נשמע קל אבל מכיוון שזה אומר שהנתונים יהיו גלויים (כמעט) לכל המשתתפים, יש לנקוט בזהירות רבה להשתמש בשיטות הערפול הנכונות עבור נתונים המוכנסים ל-Blockchain, כדי לטעון בהצלחה שפרטיות הנתונים נשמרת . אז זה קצת מסובך אבל אפשר להתגבר עליו. תחזיק חזק, מגיע מיד.
- הגנה כפולה: עכשיו זה באמת קשה כי הוא משלב את הנקודות הקודמות עם ביצוע עסקאות דטרמיניסטיות, אימות עסקאות ויצירת בלוק, שכולם מסתמכים בצורה מורכבת על האלגוריתמים ההצפנה שבהם נעשה שימוש. מבלי להיכנס לפרטים, אם אתה זקוק להגנה על הוצאה כפולה כתכונה מרכזית ביישום מבוסס הבלוקצ'יין שלך, אין לך מזל לגבי תאימות ל-NIST ... אם הנכס הדיגיטלי שלך נולד ב- Blockchain! עוד שנייה נחזור לנקודה הזו.
- הורשת ערבויות אבטחה בלוקצ'יין: זה נראה ברור. אם האבטחה שלך מסתמכת באופן קריטי על האבטחה של הבלוקצ'יין הבסיסי, וה-Blockchain הזה מסתמך לאבטחתו על אלגוריתמים שאינם תואמים ל-NIST; סוף הסיפור. שוב, לא כל כך מהר. השאלה היא ערבויות אבטחה למה? אם מדובר בנכסים דיגיטליים שנולדו ב- Blockchain, אז התשובה היא זהה להגנה על Double-Spend. אבל, אם הנכסים הדיגיטליים נוצרים תחילה מה-Blockchain, ורק לאחר מכן משוכפלים אל הבלוקצ'יין, האבטחה של הנכס הדיגיטלי הזה כבר לא קשורה ביסודה לבלוקצ'יין הבסיסי, ויש לנו את אותו טיעון כמו חותמת זמן הניתנת להוכחה לנענע את עצמנו מהחידה של NIST!
הערכת ההשפעה שלעיל יכולה כעת לשמש כרשימת בדיקה מול צרכי התאימות ל-NIST של יישום Blockchain, בהתחשב בדרישות מקרה השימוש הספציפיות של אותה אפליקציה.
לפני שנמשיך ונותן שרטוט של יישום עבור יישום שאינו מבוסס בלוקצ'יין תואם ל-NIST, בואו נדבר על פרטיות נתונים. בהתחשב בקריטריונים לעיל, ותקנות פרטיות הנתונים הקיימות, הצבת אפילו נתונים מוצפנים ב- Blockchain נחשבת כרעיון מטופש, גם כאשר משתמשים באלגוריתמי הצפנה תואמי NIST. אז מה האלטרנטיבה?
תשובה: הוכחות אפס ידע (ZKPs)
ZKPs עוסקים בהצהרות מבלי לחשוף נתונים רגישים בסיסיים, למשל יתרת החשבון של תאגיד ACME היא מעל $100,000, או שקוד הנחה זה הוחל כהלכה על הזמנה זו.
ישנם סוגים רבים של ZKPs שימושיים - Merkle Proofs, Pedersen Commitments, Bulletproofs, ZK-SNARKs, ZK-STARKs, וכן הלאה. המפתח הוא להשתמש באלגוריתמים קריפטוגרפיים תואמי NIST או לא תואמי NIST בעת שימוש ב-ZKPs. אחרת, לך על זה! ZKPs הם כלי נהדר עבור ארגונים לעמוד בדרישות פרטיות הנתונים שלהם הן פנימיות והן רגולטוריות.
עכשיו אנחנו במקום להציע המלצה הגיונית כיצד לבנות אפליקציה ארגונית מבוססת בלוקצ'יין (שלא) תואמת NIST - תוכנית.
עלויות הפריסה והתפעול בפועל אינן זמינות לציבור, אך בהתבסס על הידע של המחברים נע בין שמונה למספרים נחמדים בדולר ארה"ב עם עלויות תפעול בדרך כלל בטווח של 15 - 25% - ראה גם כמה הפניות כאן ו כאן. טווחי עלויות אלו אופייניים להטמעות ופעולות של מערכות ארגוניות בקנה מידה גדול כגון מערכות ERP.
מקור ה-FISMA Act וחוזר OMB A-130, באחריותן של סוכנויות לוודא שהסיכון בשימוש במערכת מידע לביצוע פעילויות כמו גישה, העברה, אחסון, עיבוד של נתונים פדרליים נקבע והתקבל וכי ATO אושרה למערכות כאלה.
כפי שהאיור מראה, אנו מתחילים עם ערימת תוכנה ארגונית מסורתית בחלק העליון - ראשית, שכבת היישומים, לאחר מכן שכבת ההפשטה של האפליקציה ולאחר מכן שכבת התווך - עם כל התאימות הנדרשת, למשל תאימות NIST מובנית. בתחתית הערימה, יש לנו בלוקצ'יין ציבורי מכיוון שזה מייתר את הצורך של ארגונים לבנות קונסורציונים מורכבים, להוציא הרבה כסף ולאפשר להם לנוע הרבה יותר מהר עם פיתוח מוצרים חדשים. בין תוכנת הביניים לשכבת הבלוקצ'יין הציבורית, נמצאת שכבת העיבוד ה"קסם" המתמקדת בפרטיות ובמהירות. מכיוון שהמחסנית תשתמש ב-ZKP ששומרים על הפרטיות ולא תשתמש בעיקר בנכסים דיגיטליים שנוצרו ב-Blockchain הציבורי, חששות קודמות לגבי השימוש בבלוקצ'יין ציבורי נעלמו לפתע. כפי שמציינים החצים למעלה ולמטה בצד שמאל של האיור, אבטחת הערימה עולה ככל שאנו עוברים מהשכבה העליונה לתחתית, הבלוקצ'יין הציבורי. ההפך הגמור קורה עם שלושת מאפייני המפתח האחרים - פרטיות, מהירות ושליטה; הם גדלים מהשכבה התחתונה לשכבה העליונה שבה לארגון יחיד יש שליטה מלאה על כל הנתונים, ולכן יכולים להבטיח פרטיות תוך שמירה על מהירות גבוהה / מדרגיות אפילו עבור הנתונים הרגישים ביותר. עם זאת, זה לא אומר שהפרטיות, המהירות והשליטה נמוכים לקראת תחתית הערימה, זה רק אומר שהם גבוהים יותר בשכבות העליונות של הערימה מאשר בתחתית.
עכשיו, מה לגבי שכבת העיבוד/רשת ה"קסם" הזו?
הנה מה שכבה זו יכולה לעשות באמצעות טכנולוגיה קיימת כדי לעמוד בדרישות הארגוניות:
- פרטיות מידע
- הוכחות אפס ידע של עסקאות
- הצפנה חזקה (במידת הצורך)
- טכניקות הצפנה אחרונות כגון אלגוריתמים מאובטחים קוונטיים
- אבטחה
- יורש את ערבויות האבטחה מה-Blockchain הציבורי בעת שימוש ב-ZKPs הנכונים המעוגנים בבלוקצ'יין
- נתוני נכסים דיגיטליים יכולים להיות זמינים ישירות דרך ZKPs ב- Blockchain הציבורי לשימוש במידת הצורך
- אימות
- כל אחד יכול לאמת הוכחות ב- Blockchain הציבורי
- הוכחות יכולות לאמת באופן רקורסיבי את כל עסקאות הנכס ואת כל היסטוריית עסקאות הנכס
- שום דבר אינו סופי עד שההוכחות מאומתות ב- Blockchain הציבורי
- מהירות
- מקבילה של עסקאות
- גלגלת עסקאות על ידי אצווה שלהן עם הוכחות (רקורסיביות).
- פחות עלות לעסקה
לסיכום, יש לשכבת העיבוד "קסם".
- אותן הבטחות אבטחה שבהן השתמש הבלוקצ'יין הציבורי,
- מדרגיות פי 100-1000,
- זמינות נתונים מובטחת,
- הפרטיות נשמרת בכל עת,
- עמלות עסקה נמוכות בהרבה,
- אימות של כל ההוכחות על ידי כל אחד בבלוקצ'יין הציבורי
- מאפשר KYC ו-AML
זה נשמע טוב מכדי להיות אמיתי. האם טכנולוגיה כזו כבר קיימת? התשובה היא כן, וחברות כמו Starkware, Aztec, zkSync ואחרות עובדות על הכנה מלאה של טכנולוגיות ה-ZK-Rollup "Layer 2" שלהן לארגונים. המוקד לכל המאמצים הללו הוא Ethereum הציבורי מכיוון שהוא מציע את ערבויות האבטחה הגבוהות ביותר (מספר כורים/מאמתים ו-total-value-locked (TVL)), בשילוב עם התמיכה ההצפנה הנדרשת המובנית בשכבת הביצוע שלו.
באופן טבעי, זו לא הגישה האפשרית היחידה ליישום מבוסס בלוקצ'יין להשגת ATO ממשלתי. עם זאת, זו גישה די פשוטה, ועד עכשיו מובנת היטב.
אז מה זה ה-net-net כאן?
למפעלים יש עכשיו
- A במסגרת להעריך את צרכי מקרה השימוש לעומת מאפייני בלוקצ'יין, וכיצד ניתן לענות על צרכים אלה על ידי יישומים ארגוניים מבוססי בלוקצ'יין שיכולים להשיג ATO ממשלתי.
- A תכנית אב לבנות יישומים ארגוניים מבוססי בלוקצ'יין באופן שיאפשר להם להשיג ATO ממשלתי תוך, כפי שמתואר באיור לעיל, גם לאפשר יתרונות נוספים:
- אמון גבוה יותר באמצעות Blockchains ציבוריים, אימות ציבורי והצפנה אוכפו פרטיות
- עלות נמוכה יותר באמצעות יכולת ביקורת קלה יותר (אימות ZKPs מהיר וזול) וגיבוש עסקאות מפואר (רולאפים) ביישום Layer 2
- עיבוד מהיר יותר באמצעות מקבילה של מחשוב, יותר עסקאות באמצעות רול-אפים וטביעת רגל קטנה יותר של בלוקצ'יין מכיוון ש- Blockchains ציבוריים אמורים להיות איטיים בתכנון על מנת לספק יותר אבטחה
- יותר גמישות ובחירה באמצעות היכולת להחזיק נכסים מסורתיים לבסיס נכסי קריפטו בבלוקצ'יין, אינטגרציה פשוטה יותר בין שכבה 2 לבלוקצ'יין ציבורי, והרחבה קלה של נכסי שכבה 2 לתוך למשל המערכות האקולוגיות הקיימות של DeFi
לסיום, חשוב לציין שבדוגמה של ממשלת ארה"ב, השגת ATO עבור מערכת מידע אינה מוגבלת רק לחפצים קריפטוגרפיים ולמודולי קריפטו. אלה מייצגים חלק חשוב מבקרות האבטחה שמזוהות במהלך תהליך ניהול הסיכונים הדרוש להשגת ATO, כפי שרשום והוסבר בפירוט נרחב ב-NIST SP 800-37 Rev 2 ו-NIST FIPS-199. התהליך כולל גם אלמנטים כגון אימות/הרשאה של משתמשים תחת תרחישי שימוש שונים, בקרות לשינויי מערכת ותהליכים, התאוששות מאסון והמשכיות עסקית.
האם תאימות ATO/NIST ליישומי Blockchain רלוונטית לעסק שלך? קבוצת העבודה של EEA ATO תרצה את הערתך. אנא צור קשר .
עקבו אחרינו ב טויטר, לינקדין ו פייסבוק כדי להישאר מעודכן בכל הקשור ל-EEA.
