שורש בלוקצ'יין של אמון ליצירות דיגיטליות

אכיפת זכויות דיגיטליות להפעלת המכשיר הספציפי בלבד הייתה אתגר אבטחה נפרד לחלוטין, אך היא הייתה חיונית לאוטומציה של ניהול נכסי תוכנה (SAM). זה רצון נפוץ שכל אסימון Activate יאשר רק מוצר בודד במכשיר בודד בכל פעם (מחשב נייד, טאבלט, טלפון וכו'). ישנם אמצעים אחרים לנעילת הפעלה מלבד מזהה מכשיר - אלה לא יידונו אך יכולים להשתלב באותו אופן. כאשר לכל מכשיר יש מזהי חומרה בלתי ניתנים לשינוי, ניתן היה להשתמש באחד או יותר מהם כמזהה ההפעלה. אמנם שונה עבור כל מערכת הפעלה של התקן, הנה דוגמה לשימוש ב-Linux dbus/machine-id כמזהה החומרה הייחודי. עבור Windows, התהליך דומה למעט שאנו משתמשים בממשק SMB/BIOS כדי לגשת ל-MachineGuid לקריאה בלבד ברישום.

/ ************************************************* **************** /
/* AutoLmMachineId: מצא והחזר את ה-Unix Dbus machine-id */
/ * * /
/* כניסות: comp_id = OUT את ה-dbus machine-id מ-Unix */
/ * * /
/* מחזירה: OUT comp_id length אם הצלחה, אחרת שגיאה */
/ * * /
/ ************************************************* **************** /
// קבל את MachineId במחרוזת, בפורמט הקסדצימלי
// OUT: גודל מערך comp_id חייב להיות 35 בתים או יותר
int AutoLmMachineId(char *comp_id)
{
char tmp[64];
קובץ *pFILE; tmp[0] = 0;
pFILE = fopen("/var/lib/dbus/machine-id", "r");
if(pFILE) {
fgets(tmp, 32, pFILE);
tmp[32] = 0;
}
sprintf(comp_id, "0x%s", tmp);
החזר strlen(comp_id); // החזר אורך מחרוזת
}

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

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

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

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

 / / / @הודעה החזר ערך הפעלת משתמש ותפוגה עבור המוצר
/// הישות והמוצר חייבים להיות תקפים.
/ / / @ פארם entityIndex הישות שעבורה מיועד רישיון המוצר
/ / / @ פארם productIndex המזהה הספציפי של המוצר
/ / / @ פארם licenseHash את המזהה הייחודי החיצוני להפעלה
/ / / @לַחֲזוֹר ערך ההפעלה (דגלים, תפוגה, ערך)
/ / / @לַחֲזוֹר המחיר באסימונים שהוא מוצע למכירה חוזרת
function activateStatus(uint256 entityIndex, uint256 productIndex,
uint256 licenseHash)
תצוגה חיצונית מחזירה (uint256, uint256)
{
require(entityIndex > 0, EntityIsZero);
uint256 tokenId = ActivateIdToTokenId[licenseHash]; if (קוד ID > 0)
{
require(entityIndex == (tokenId & EntityIdMask) >>
EntityIdOffset, "EntityId לא תואם");
require(productIndex == (tokenId & ProductIdMask) >>
ProductIdOffset, "ProductId לא תואם");
} // החזר דגלי רישיון, ערך. תפוגה ומחיר
חזור
(tokenId & (FlagsMask | //flags
מסכת תפוגה | //תפוגה
ValueMask)), //value
TokenIdToOfferPrice[tokenId] //price
);
}

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

כאשר בדיקת הפעלת הרישיון בחוזים החכמים מבטיחה שמזהי המוצר והארגון הנכונים קיימים, ארנק ה-Ethereum שנרשם על ידי הבעלים של אותו מוצר הוא האמצעי הבריא היחיד להטביע (כלומר ליצור) את האסימונים הללו. עם זאת, ניתן ליצור אישורים מזויפים/NFTs עם מזהה זהה ברשת Ethereum מבחן מכיוון שהחוזים החכמים שלנו הם קוד פתוח כדי לאפשר ביקורת אבטחה של צד שלישי ופריסות בלוקצ'יין פרטיות. כדי למנוע ממערכת אקולוגית בלתי רשמית לא רשמית להתחזות לשלך, חשוב שהתוכנה שמבטיחה את בקשת הקריאה לבלוקצ'יין (Infura וכו') תשתמש ב-Ethereum Mainnet ובכתובת החוזה הרשמית של Ecosystem שלנו. מתן אפשרויות בעת הגדרת גישה לבלוקצ'יין עלול להשאיר את הנתיב לשימוש בעת אימות אישורי בלוקצ'יין מחוץ לשליטתך. עיצוב זה נדרש מכיוון שהוא מאפשר לפרוס את המערכת האקולוגית ברשתות Ethereum פרטיות כדי למנוע עלויות גז ETH.

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

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

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

מקור: https://betterprogramming.pub/a-blockchain-root-of-trust-for-digital-works-4726bbeb3c7e?source=rss——-8—————–cryptocurrency