DPKI: رفع نواقص PKI متمرکز با استفاده از بلاک چین

بر کسی پوشیده نیست که یکی از ابزارهای کمکی رایج که بدون آن حفاظت از داده ها در شبکه های باز غیرممکن است، فناوری گواهی دیجیتال است. با این حال، بر کسی پوشیده نیست که ایراد اصلی فناوری اعتماد بی قید و شرط به مراکز صادر کننده گواهی دیجیتال است. مدیر فناوری و نوآوری در ENCRY آندری چمورا رویکرد جدیدی برای سازماندهی پیشنهاد کرد زیرساخت کلید عمومی (زیرساخت کلید عمومی، PKI) که به رفع نواقص فعلی کمک می کند و از فناوری دفتر کل توزیع شده (بلاک چین) استفاده می کند. اما اول از همه.

اگر با نحوه عملکرد زیرساخت کلید عمومی فعلی خود آشنا هستید و از کاستی‌های کلیدی آن اطلاع دارید، می‌توانید به آنچه در زیر پیشنهاد می‌کنیم تغییر دهید ادامه دهید.

امضا و گواهی دیجیتال چیست؟تعامل در اینترنت همیشه شامل انتقال داده است. همه ما علاقه مندیم که داده ها به طور ایمن منتقل شوند. اما امنیت چیست؟ بیشترین خدمات امنیتی که به دنبال آن هستند رازداری، صداقت و اصالت هستند. برای این منظور در حال حاضر از روش های رمزنگاری نامتقارن یا رمزنگاری با کلید عمومی استفاده می شود.

بیایید با این واقعیت شروع کنیم که برای استفاده از این روش ها، موضوعات تعامل باید دو کلید زوجی جداگانه داشته باشند - عمومی و مخفی. با کمک آنها خدمات امنیتی که در بالا ذکر کردیم ارائه می شود.

محرمانه بودن انتقال اطلاعات چگونه حاصل می شود؟ قبل از ارسال داده ها، مشترک فرستنده با استفاده از کلید عمومی گیرنده، داده های باز را رمزگذاری می کند (تبدیل رمزنگاری می کند)، و گیرنده متن رمز دریافتی را با استفاده از کلید مخفی جفت شده رمزگشایی می کند.

یکپارچگی و صحت اطلاعات ارسالی چگونه به دست می آید؟ برای حل این مشکل مکانیسم دیگری ایجاد شد. داده های باز رمزگذاری نمی شوند، اما نتیجه اعمال تابع هش رمزنگاری - یک تصویر "فشرده" از توالی داده های ورودی - به شکل رمزگذاری شده منتقل می شود. نتیجه چنین هش‌سازی «هضم» نامیده می‌شود و با استفاده از کلید مخفی مشترک فرستنده («شاهد») رمزگذاری می‌شود. در نتیجه رمزگذاری خلاصه، یک امضای دیجیتال به دست می آید. همراه با متن واضح، به مشترک گیرنده ("تأیید کننده") منتقل می شود. او امضای دیجیتالی روی کلید عمومی شاهد را رمزگشایی می‌کند و آن را با نتیجه اعمال یک تابع هش رمزنگاری که تأییدکننده به طور مستقل بر اساس داده‌های باز دریافتی محاسبه می‌کند، مقایسه می‌کند. اگر آنها مطابقت داشته باشند، این نشان می دهد که داده ها به صورت معتبر و کامل توسط مشترک فرستنده منتقل شده است، و توسط یک مهاجم اصلاح نشده است.

اکثر منابعی که با داده‌های شخصی و اطلاعات پرداخت کار می‌کنند (بانک‌ها، شرکت‌های بیمه، خطوط هوایی، سیستم‌های پرداخت، و همچنین پورتال‌های دولتی مانند خدمات مالیاتی) به طور فعال از روش‌های رمزنگاری نامتقارن استفاده می‌کنند.

گواهی دیجیتال چه ربطی به آن دارد؟ ساده است. هر دو فرآیند اول و دوم شامل کلیدهای عمومی هستند، و از آنجایی که آنها نقش اصلی را ایفا می کنند، بسیار مهم است که اطمینان حاصل شود که کلیدها واقعاً به فرستنده (شاهد، در مورد تأیید امضا) یا گیرنده تعلق دارند و نیستند. با کلیدهای مهاجمان جایگزین شده است. به همین دلیل است که گواهی های دیجیتال برای اطمینان از صحت و یکپارچگی کلید عمومی وجود دارد.

نکته: اصالت و یکپارچگی کلید عمومی دقیقاً به همان روشی که صحت و صحت داده های عمومی یعنی با استفاده از امضای دیجیتال الکترونیکی (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 قرارداد مشترکی منعقد کرده اند ارائه می شود. مشترک می تواند به طور همزمان کاربر گواهی باشد.

بنابراین، نهادهای مورد اعتماد زیرساخت کلید عمومی، که شامل CA، CR و دایرکتوری‌های باز است، مسئول موارد زیر هستند:

1. تأیید صحت هویت متقاضی.
2. پروفایل گواهی کلید عمومی.
3. صدور گواهی کلید عمومی برای متقاضی که هویت او به طور قابل اعتماد تایید شده است.
4. وضعیت گواهی کلید عمومی را تغییر دهید.
5. ارائه اطلاعات در مورد وضعیت فعلی گواهی کلید عمومی.

معایب PKI، آنها چیست؟نقص اساسی PKI وجود نهادهای قابل اعتماد است.
کاربران باید بدون قید و شرط به CA و CR اعتماد کنند. اما، همانطور که تمرین نشان می دهد، اعتماد بی قید و شرط مملو از عواقب جدی است.

در طول ده سال گذشته، چندین رسوایی بزرگ در این زمینه در ارتباط با آسیب پذیری زیرساخت ها وجود داشته است.

— در سال 2010 بدافزار استاکس نت به صورت آنلاین گسترش یافت و با استفاده از گواهینامه های دیجیتال دزدیده شده از RealTek و JMicron امضا شد.

- در سال 2017، گوگل سیمانتک را به صدور تعداد زیادی گواهی جعلی متهم کرد. در آن زمان، سیمانتک یکی از بزرگترین CAها از نظر حجم تولید بود. در مرورگر گوگل کروم 70، پشتیبانی از گواهی های صادر شده توسط این شرکت و مراکز وابسته به آن GeoTrust و Thawte قبل از 1 دسامبر 2017 متوقف شد.

CA به خطر افتاد، و در نتیجه همه آسیب دیدند - خود CA، و همچنین کاربران و مشترکان. اعتماد به زیرساخت ها تضعیف شده است. علاوه بر این، گواهی‌های دیجیتال ممکن است در چارچوب درگیری‌های سیاسی مسدود شوند که بر عملکرد بسیاری از منابع نیز تأثیر می‌گذارد. این دقیقاً همان چیزی است که چندین سال پیش در دولت ریاست جمهوری روسیه ترسیده بود، جایی که در سال 2016 آنها در مورد امکان ایجاد یک مرکز صدور گواهینامه دولتی که گواهینامه های SSL را برای سایت های RuNet صادر می کند، بحث کردند. وضعیت فعلی به گونه ای است که حتی پورتال های دولتی در روسیه استفاده کنید گواهی های دیجیتال صادر شده توسط شرکت های آمریکایی Comodo یا Thawte (یکی از شرکت های تابعه Symantec).

مشکل دیگری وجود دارد - سؤال احراز هویت اولیه (احراز هویت) کاربران. چگونه کاربری را شناسایی کنیم که با درخواست صدور گواهی دیجیتال بدون تماس مستقیم شخصی با CA تماس گرفته است؟ اکنون این به صورت موقعیتی بسته به قابلیت های زیرساخت تصمیم گیری می شود. چیزی از دفاتر ثبت باز گرفته شده است (مثلاً اطلاعات مربوط به اشخاص حقوقی که درخواست گواهی دارند)؛ در مواردی که متقاضیان اشخاص حقیقی هستند، می توان از دفاتر بانک یا دفاتر پست استفاده کرد که هویت آنها با استفاده از مدارک شناسایی، به عنوان مثال، گذرنامه تأیید می شود.

مشکل جعل اعتبارنامه به منظور جعل هویت یک مشکل اساسی است. توجه داشته باشیم که به دلایل نظری-اطلاعاتی راه حل کاملی برای این مشکل وجود ندارد: بدون داشتن اطلاعات موثق پیشینی، تأیید یا رد صحت یک موضوع خاص غیرممکن است. به عنوان یک قاعده، برای تأیید، لازم است مجموعه ای از اسناد هویت متقاضی ارائه شود. روش های مختلف تأیید وجود دارد، اما هیچ یک از آنها تضمین کاملی از صحت اسناد را ارائه نمی دهد. بر این اساس، اصالت هویت متقاضی نیز قابل تضمین نیست.

چگونه می توان این کاستی ها را برطرف کرد؟اگر مشکلات PKI در وضعیت فعلی آن را بتوان با تمرکز توضیح داد، منطقی است که فرض کنیم تمرکززدایی می تواند تا حدی به رفع کاستی های شناسایی شده کمک کند.

تمرکززدایی به معنای حضور نهادهای قابل اعتماد نیست - اگر ایجاد کنید زیرساخت کلید عمومی غیرمتمرکز (زیرساخت کلید عمومی غیرمتمرکز، DPKI، پس نه CA و نه CR مورد نیاز نیست. بیایید مفهوم گواهی دیجیتال را کنار بگذاریم و از یک رجیستری توزیع شده برای ذخیره اطلاعات کلیدهای عمومی استفاده کنیم. در مورد ما، ما یک رجیستر را یک پایگاه داده خطی می نامیم که شامل رکوردهای فردی (بلوک) است که با استفاده از فناوری بلاک چین به هم مرتبط شده اند. به جای گواهی دیجیتال، مفهوم "اعلان" را معرفی خواهیم کرد.

روند دریافت، تأیید و لغو اعلان‌ها در DPKI پیشنهادی چگونه خواهد بود:

1. هر متقاضی به طور مستقل با پر کردن فرمی در هنگام ثبت نام، درخواستی را برای اطلاع رسانی ارسال می کند و پس از آن تراکنشی را ایجاد می کند که در یک استخر تخصصی ذخیره می شود.

2. اطلاعات مربوط به کلید عمومی، همراه با جزئیات مالک و سایر ابرداده ها، در یک رجیستری توزیع شده ذخیره می شود و نه در یک گواهی دیجیتال، که مسئولیت صدور آن در یک PKI متمرکز بر عهده CA است.

3. تأیید صحت هویت متقاضی پس از این واقعیت با تلاش مشترک جامعه کاربران DPKI انجام می شود و نه توسط CR.

4. فقط صاحب چنین اعلان می تواند وضعیت کلید عمومی را تغییر دهد.

5. هر کسی می تواند به دفتر کل توزیع شده دسترسی داشته باشد و وضعیت فعلی کلید عمومی را بررسی کند.

توجه: تأیید هویت متقاضی در جامعه ممکن است در نگاه اول غیر قابل اعتماد به نظر برسد. اما باید به خاطر داشته باشیم که امروزه همه کاربران خدمات دیجیتال به ناچار ردپایی دیجیتالی از خود بر جای می‌گذارند و این روند تنها به شتاب ادامه خواهد داد. ثبت‌های الکترونیکی باز اشخاص حقوقی، نقشه‌ها، دیجیتالی کردن تصاویر زمین، شبکه‌های اجتماعی - همه اینها ابزارهای در دسترس عموم هستند. آنها در حال حاضر با موفقیت در تحقیقات توسط روزنامه نگاران و سازمان های مجری قانون استفاده می شوند. به عنوان مثال کافی است تحقیقات بلینگکت یا تیم تحقیقاتی مشترک JIT را یادآوری کنیم که در حال بررسی شرایط سقوط هواپیمای بوئینگ مالزی هستند.

بنابراین چگونه یک زیرساخت کلید عمومی غیرمتمرکز در عمل کار می کند؟ اجازه دهید در مورد توصیف خود فناوری که ما آن را توضیح می دهیم صحبت کنیم ثبت اختراع در سال 2018 و ما به حق آن را دانش خود می دانیم.

تصور کنید مالکی وجود دارد که دارای کلیدهای عمومی زیادی است، جایی که هر کلید یک تراکنش خاص است که در رجیستری ذخیره می شود. در غیاب CA، چگونه می توانید بفهمید که همه کلیدها متعلق به این مالک خاص هستند؟ برای حل این مشکل، یک تراکنش صفر ایجاد می شود که حاوی اطلاعاتی در مورد مالک و کیف پول او است (که کمیسیون قرار دادن تراکنش در رجیستری از آن کسر می شود). تراکنش تهی نوعی «لنگر» است که تراکنش‌های زیر با داده‌های مربوط به کلیدهای عمومی به آن پیوست می‌شود. هر تراکنش حاوی یک ساختار داده تخصصی یا به عبارت دیگر، یک اعلان است.

اعلان مجموعه ای ساختاریافته از داده های متشکل از فیلدهای عملکردی و شامل اطلاعات مربوط به کلید عمومی مالک است که ماندگاری آن با قرار دادن در یکی از رکوردهای مرتبط با ثبت توزیع شده تضمین می شود.

سوال منطقی بعدی این است که تراکنش صفر چگونه شکل می گیرد؟ تراکنش تهی - مانند تراکنش‌های بعدی - ترکیبی از شش فیلد داده است. در طول تشکیل تراکنش صفر، جفت کلید کیف پول درگیر می شود (کلیدهای مخفی عمومی و جفت شده). این جفت کلید در لحظه ای ظاهر می شود که کاربر کیف پول خود را ثبت می کند که از آن کمیسیون برای قرار دادن تراکنش صفر در رجیستری و متعاقباً عملیات همراه با اعلان ها کسر می شود.

همانطور که در شکل نشان داده شده است، یک خلاصه کلید عمومی کیف پول با اعمال متوالی توابع هش SHA256 و RIPEMD160 تولید می شود. در اینجا RIPEMD160 مسئول نمایش فشرده داده ها است که عرض آنها از 160 بیت تجاوز نمی کند. این مهم است زیرا رجیستری یک پایگاه داده ارزان نیست. خود کلید عمومی در قسمت پنجم وارد می شود. فیلد اول حاوی داده هایی است که ارتباطی را با تراکنش قبلی برقرار می کند. برای تراکنش صفر، این فیلد حاوی هیچ چیزی نیست که آن را از تراکنش های بعدی متمایز می کند. فیلد دوم داده هایی برای بررسی اتصال تراکنش ها است. برای اختصار، داده های فیلد اول و دوم را به ترتیب «پیوند» و «بررسی» می نامیم. محتویات این فیلدها با هش تکراری تولید می شوند، همانطور که با پیوند دادن تراکنش های دوم و سوم در شکل زیر نشان داده شده است.

داده های پنج فیلد اول توسط یک امضای الکترونیکی تأیید می شود که با استفاده از کلید مخفی کیف پول تولید می شود.

تمام است، تراکنش تهی به استخر ارسال می شود و پس از تأیید موفقیت آمیز وارد رجیستری می شود. اکنون می توانید تراکنش های زیر را به آن "پیوند" کنید. بیایید در نظر بگیریم که تراکنش های غیر از صفر چگونه شکل می گیرند.

اولین چیزی که احتمالاً توجه شما را به خود جلب کرد، فراوانی جفت کلید است. علاوه بر جفت کلید کیف پول از قبل آشنا، از جفت کلید معمولی و سرویس استفاده می شود.

یک کلید عمومی معمولی چیزی است که همه چیز برای آن شروع شده است. این کلید در رویه‌ها و فرآیندهای مختلفی که در دنیای خارج آشکار می‌شوند (بانکداری و سایر معاملات، جریان اسناد و غیره) دخالت دارد. به عنوان مثال می توان از یک کلید مخفی از یک جفت معمولی برای تولید امضای دیجیتال برای اسناد مختلف - دستور پرداخت و غیره استفاده کرد و با اجرای بعدی این دستورالعمل ها می توان از کلید عمومی برای تأیید این امضای دیجیتال استفاده کرد، مشروط بر اینکه معتبر است.

جفت سرویس برای موضوع DPKI ثبت شده صادر می شود. نام این جفت با هدف آن مطابقت دارد. توجه داشته باشید که هنگام تشکیل/بررسی تراکنش صفر، از کلیدهای سرویس استفاده نمی شود.

بیایید دوباره هدف کلیدها را روشن کنیم:

1. کلیدهای کیف پول برای ایجاد/تأیید تراکنش تهی و هر تراکنش غیر تهی دیگر استفاده می شود. کلید خصوصی یک کیف پول فقط برای صاحب کیف پول شناخته شده است، او همچنین صاحب بسیاری از کلیدهای عمومی معمولی است.
2. یک کلید عمومی معمولی از نظر هدف مشابه کلید عمومی است که برای آن گواهی در یک PKI متمرکز صادر شده است.
3. جفت کلید سرویس متعلق به DPKI است. کلید مخفی برای اشخاص ثبت شده صادر می شود و هنگام تولید امضای دیجیتال برای تراکنش ها (به جز تراکنش های صفر) استفاده می شود. عمومی برای تأیید امضای دیجیتال الکترونیکی تراکنش قبل از ارسال در رجیستری استفاده می شود.

بنابراین، دو گروه از کلیدها وجود دارد. اولین مورد شامل کلیدهای سرویس و کلیدهای کیف پول است - آنها فقط در زمینه DPKI معنی دارند. گروه دوم شامل کلیدهای معمولی است - دامنه آنها ممکن است متفاوت باشد و با وظایف برنامه ای که در آنها استفاده می شود تعیین می شود. در عین حال، DPKI یکپارچگی و اصالت کلیدهای عمومی معمولی را تضمین می کند.

توجه: ممکن است جفت کلید سرویس برای نهادهای مختلف DPKI شناخته شده باشد. مثلا ممکن است برای همه یکسان باشد. به همین دلیل است که هنگام ایجاد امضای هر تراکنش غیر صفر، از دو کلید مخفی استفاده می شود که یکی از آنها کلید کیف پول است - فقط صاحب کیف پول که صاحب بسیاری از موارد معمولی است می شناسد. کلیدهای عمومی همه کلیدها معنای خاص خود را دارند. به عنوان مثال، همیشه می توان ثابت کرد که تراکنش توسط یک موضوع ثبت شده DPKI وارد رجیستری شده است، زیرا امضا نیز روی یک کلید سرویس مخفی ایجاد شده است. و هیچ سوء استفاده ای مانند حملات DOS وجود ندارد، زیرا مالک برای هر تراکنش پرداخت می کند.

همه تراکنش هایی که از صفر یک پیروی می کنند به روشی مشابه شکل می گیرند: کلید عمومی (نه کیف پول، مانند تراکنش صفر، بلکه از یک جفت کلید معمولی) از طریق دو تابع هش SHA256 و RIPEMD160 اجرا می شود. به این ترتیب داده های فیلد سوم تشکیل می شود. قسمت چهارم حاوی اطلاعات همراه است (به عنوان مثال، اطلاعات مربوط به وضعیت فعلی، تاریخ انقضا، مهر زمانی، شناسه های الگوریتم های رمزنگاری استفاده شده و غیره). فیلد پنجم شامل کلید عمومی از جفت کلید سرویس است. با کمک آن، امضای دیجیتال سپس بررسی می شود، بنابراین تکرار می شود. اجازه دهید نیاز به چنین رویکردی را توجیه کنیم.

به یاد داشته باشید که یک تراکنش در یک استخر وارد می شود و تا زمانی که پردازش شود در آنجا ذخیره می شود. ذخیره سازی در یک استخر با خطر خاصی همراه است - داده های تراکنش را می توان جعل کرد. مالک داده های تراکنش را با امضای دیجیتال الکترونیکی تأیید می کند. کلید عمومی برای تأیید این امضای دیجیتال به صراحت در یکی از فیلدهای تراکنش نشان داده شده و متعاقباً وارد رجیستری می شود. ویژگی های پردازش تراکنش به گونه ای است که مهاجم می تواند داده ها را به صلاحدید خود تغییر دهد و سپس با استفاده از کلید مخفی خود آن را تأیید کند و یک کلید عمومی جفت شده برای تأیید امضای دیجیتال در تراکنش نشان دهد. اگر اصالت و یکپارچگی منحصراً از طریق امضای دیجیتال تضمین شود، چنین جعلی مورد توجه قرار نخواهد گرفت. با این حال، اگر علاوه بر امضای دیجیتال، مکانیسم اضافی وجود داشته باشد که هم آرشیو و هم ماندگاری اطلاعات ذخیره شده را تضمین کند، جعل قابل تشخیص است. برای این کار کافی است کلید عمومی اصلی مالک را وارد رجیستری کنید. بیایید توضیح دهیم که چگونه این کار می کند.

اجازه دهید مهاجم داده های تراکنش را جعل کند. از نظر کلیدها و امضاهای دیجیتال، گزینه های زیر امکان پذیر است:

1. مهاجم کلید عمومی خود را در معامله قرار می دهد در حالی که امضای دیجیتال مالک بدون تغییر باقی می ماند.
2. مهاجم یک امضای دیجیتال روی کلید خصوصی خود ایجاد می کند، اما کلید عمومی مالک را بدون تغییر می گذارد.
3. مهاجم یک امضای دیجیتالی روی کلید خصوصی خود ایجاد می کند و یک کلید عمومی جفت شده را در تراکنش قرار می دهد.

بدیهی است که گزینه های 1 و 2 بی معنی هستند، زیرا آنها همیشه در حین تأیید امضای دیجیتال شناسایی می شوند. تنها گزینه 3 منطقی است، و اگر مهاجم یک امضای دیجیتالی را روی کلید مخفی خود ایجاد کند، مجبور است یک کلید عمومی جفت شده را در تراکنش ذخیره کند، متفاوت از کلید عمومی مالک. این تنها راهی است که مهاجم می تواند داده های جعلی را تحمیل کند.

بیایید فرض کنیم که مالک دارای یک جفت کلید ثابت است - خصوصی و عمومی. اجازه دهید داده ها با امضای دیجیتال با استفاده از کلید مخفی این جفت تأیید شوند و کلید عمومی در تراکنش نشان داده شود. همچنین فرض کنید که این کلید عمومی قبلاً وارد رجیستری شده است و صحت آن به طور قابل اعتماد تأیید شده است. سپس جعل با این واقعیت نشان داده می شود که کلید عمومی معامله با کلید عمومی از رجیستری مطابقت ندارد.

بیایید خلاصه کنیم هنگام پردازش اولین داده های تراکنش مالک، لازم است صحت کلید عمومی وارد شده در رجیستری را تأیید کنید. برای انجام این کار، کلید را از رجیستری بخوانید و آن را با کلید عمومی واقعی مالک در محدوده امنیتی (منطقه آسیب ناپذیری نسبی) مقایسه کنید. اگر اصالت کلید تایید شود و ماندگاری آن در هنگام قرار دادن تضمین شود، می توان با مقایسه آن با کلید رجیستری، صحت کلید از تراکنش بعدی را تایید/رد کرد. به عبارت دیگر، کلید از رجیستری به عنوان نمونه مرجع استفاده می شود. تمام معاملات مالک دیگر به طور مشابه پردازش می شوند.

این تراکنش با امضای دیجیتال الکترونیکی تأیید می شود - اینجاست که کلیدهای مخفی مورد نیاز است و نه یک، بلکه دو در یک بار - یک کلید خدمات و یک کلید کیف پول. به لطف استفاده از دو کلید مخفی، سطح امنیتی لازم تضمین می شود - از این گذشته، کلید مخفی سرویس را می توان برای سایر کاربران شناخت، در حالی که کلید مخفی کیف پول فقط برای صاحب جفت کلید معمولی شناخته شده است. ما چنین امضای دو کلیدی را امضای دیجیتال "تلفیقی" نامیدیم.

تأیید تراکنش‌های غیر پوچ با استفاده از دو کلید عمومی انجام می‌شود: کیف پول و کلید سرویس. فرآیند تأیید را می توان به دو مرحله اصلی تقسیم کرد: مرحله اول بررسی خلاصه کلید عمومی کیف پول، و دوم بررسی امضای دیجیتال الکترونیکی تراکنش است، همان مرحله تلفیقی که با استفاده از دو کلید مخفی شکل گرفته است. کیف پول و خدمات). اگر اعتبار امضای دیجیتال تأیید شود، پس از تأیید اضافی، تراکنش به ثبت وارد می شود.

ممکن است یک سوال منطقی مطرح شود: چگونه می توان بررسی کرد که آیا یک تراکنش به یک زنجیره خاص با "ریشه" در قالب یک تراکنش صفر تعلق دارد؟ برای این منظور، فرآیند تأیید با یک مرحله دیگر تکمیل می شود - بررسی اتصال. اینجاست که ما به داده های دو فیلد اول نیاز خواهیم داشت که تاکنون از آنها چشم پوشی کرده ایم.

بیایید تصور کنیم که باید بررسی کنیم که آیا تراکنش شماره 3 واقعاً بعد از تراکنش شماره 2 می آید یا خیر. برای این کار با استفاده از روش هش ترکیبی، مقدار تابع هش برای داده های فیلدهای سوم، چهارم و پنجم تراکنش شماره 2 محاسبه می شود. سپس الحاق داده ها از فیلد اول تراکنش شماره 3 و مقدار تابع هش ترکیبی قبلاً به دست آمده برای داده های فیلدهای سوم، چهارم و پنجم تراکنش شماره 2 انجام می شود. همه اینها همچنین از طریق دو تابع هش SHA256 و RIPEMD160 اجرا می شوند. اگر مقدار دریافتی با داده های فیلد دوم تراکنش شماره 2 مطابقت داشته باشد، چک پاس شده و اتصال تایید می شود. این موضوع در شکل های زیر با وضوح بیشتری نشان داده شده است.

به طور کلی، فناوری تولید و وارد کردن اعلان در رجیستر دقیقاً به این صورت است. یک تصویر بصری از فرآیند تشکیل زنجیره ای از اعلان ها در شکل زیر ارائه شده است:

در این متن، به جزئیاتی که بدون شک وجود دارد نمی پردازیم و به بحث در مورد ایده یک زیرساخت کلید عمومی غیرمتمرکز باز می گردیم.

بنابراین، از آنجایی که خود متقاضی درخواستی را برای ثبت اعلان ها ارسال می کند که نه در پایگاه داده CA، بلکه در رجیستری ذخیره می شوند، اجزای اصلی معماری DPKI باید در نظر گرفته شوند:

1. ثبت اطلاعیه های معتبر (RDN).
2. ثبت اطلاعیه های لغو شده (RON).
3. ثبت اعلان های تعلیق شده (RPN).

اطلاعات مربوط به کلیدهای عمومی در RDN/RON/RPN به شکل مقادیر تابع هش ذخیره می شود. همچنین شایان ذکر است که اینها می توانند رجیستری های مختلف یا زنجیره های مختلف یا حتی یک زنجیره به عنوان بخشی از یک رجیستری واحد باشند، زمانی که اطلاعات مربوط به وضعیت یک کلید عمومی معمولی (ابطال، تعلیق و غیره) وارد می شود. قسمت چهارم ساختار داده در قالب مقدار کد مربوطه. گزینه های مختلفی برای اجرای معماری DPKI وجود دارد و انتخاب یکی یا دیگری به عوامل مختلفی بستگی دارد، به عنوان مثال، معیارهای بهینه سازی مانند هزینه حافظه بلند مدت برای ذخیره کلیدهای عمومی و غیره.

بنابراین، DPKI ممکن است اگر ساده‌تر نباشد، حداقل قابل مقایسه با یک راه‌حل متمرکز از نظر پیچیدگی معماری باشد.

سوال اصلی باقی می ماند - کدام رجیستری برای پیاده سازی فناوری مناسب است؟

نیاز اصلی برای رجیستری، توانایی ایجاد تراکنش از هر نوع است. معروف ترین نمونه دفتر کل، شبکه بیت کوین است. اما هنگام اجرای فناوری توضیح داده شده در بالا، مشکلات خاصی ایجاد می شود: محدودیت های زبان برنامه نویسی موجود، فقدان مکانیسم های لازم برای پردازش مجموعه های دلخواه از داده ها، روش هایی برای ایجاد تراکنش های یک نوع دلخواه و موارد دیگر.

ما در ENCRY سعی کردیم مشکلات فرموله شده در بالا را حل کنیم و یک رجیستری ایجاد کردیم که به نظر ما دارای تعدادی مزیت است که عبارتند از:

• چندین نوع تراکنش را پشتیبانی می کند: هم می تواند دارایی ها را مبادله کند (یعنی تراکنش های مالی را انجام دهد) و هم می تواند تراکنش هایی با ساختار دلخواه ایجاد کند.
• توسعه دهندگان به زبان برنامه نویسی اختصاصی PrismLang دسترسی دارند که انعطاف پذیری لازم را هنگام حل مشکلات مختلف تکنولوژیکی فراهم می کند.
• مکانیزمی برای پردازش مجموعه داده های دلخواه ارائه شده است.

اگر یک رویکرد ساده را در نظر بگیریم، دنباله اقدامات زیر انجام می شود:

1. متقاضی در DPKI ثبت نام می کند و یک کیف پول دیجیتال دریافت می کند. آدرس کیف پول، مقدار هش کلید عمومی کیف پول است. کلید خصوصی کیف پول فقط برای متقاضی شناخته شده است.
2. به موضوع ثبت نام شده دسترسی به کلید مخفی سرویس داده می شود.
3. سوژه یک تراکنش صفر ایجاد می کند و با استفاده از کلید مخفی کیف پول آن را با امضای دیجیتال تأیید می کند.
4. اگر تراکنشی غیر از صفر تشکیل شود، با امضای دیجیتال الکترونیکی با استفاده از دو کلید مخفی تأیید می شود: یک کیف پول و یک کلید خدمات.
5. موضوع معامله را به استخر ارسال می کند.
6. گره شبکه ENCRY تراکنش را از استخر می خواند و امضای دیجیتال و همچنین اتصال تراکنش را بررسی می کند.
7. اگر امضای دیجیتال معتبر باشد و اتصال تایید شود، تراکنش را برای ورود به ثبت آماده می کند.

در اینجا رجیستری به عنوان یک پایگاه داده توزیع شده عمل می کند که اطلاعات مربوط به اعلان های معتبر، لغو شده و تعلیق شده را ذخیره می کند.

البته تمرکززدایی نوشدارویی نیست. مشکل اساسی احراز هویت کاربر اولیه در هیچ کجا ناپدید نمی شود: اگر در حال حاضر تأیید متقاضی توسط CR انجام می شود، در DPKI پیشنهاد می شود تأیید را به اعضای جامعه واگذار کنید و از انگیزه مالی برای تحریک فعالیت استفاده کنید. فناوری تأیید منبع باز به خوبی شناخته شده است. اثربخشی چنین تأییدی در عمل تأیید شده است. اجازه دهید دوباره تعدادی از تحقیقات برجسته توسط نشریه آنلاین بلینگکت را به یاد بیاوریم.

اما به طور کلی، تصویر زیر ظاهر می شود: DPKI فرصتی برای اصلاح، اگر نه همه، بسیاری از کاستی های PKI متمرکز است.

در هابرابلاگ ما مشترک شوید، ما قصد داریم به طور فعال تحقیق و توسعه خود را پوشش دهیم و دنبال کنیم توییتر، اگر نمی خواهید اخبار دیگر در مورد پروژه های ENCRY را از دست بدهید.

منبع: www.habr.com