امروزه همه در مورد فناوری بلاکچین، ارزهای دیجیتال و جذابیت‌های آن مطلب نوشته‌اند. اما این مقاله قصد ندارد از این فناوری تجلیل کند؛ بلکه بر کاستی‌های آن و چگونگی رفع آنها تمرکز خواهد کرد.

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

مشکل این است که خود بلاکچین یک نهاد مستقل و بسته است، بنابراین قراردادهای هوشمند درون آن چیزی در مورد دنیای خارج نمی‌دانند. در عین حال، شرایط قراردادهای هوشمند اغلب به اطلاعات مربوط به اشیاء دنیای واقعی (تأخیر پروازها، نرخ ارز و غیره) مرتبط هستند. برای اینکه قراردادهای هوشمند به درستی کار کنند، اطلاعات دریافتی از خارج از بلاکچین باید قابل اعتماد و تأیید شده باشند. این مشکل با استفاده از اوراکل‌هایی مانند Town Crier و DECO حل می‌شود. این اوراکل‌ها به یک قرارداد هوشمند در شبکه بلاکچین اجازه می‌دهند تا به اطلاعات یک وب سرور قابل اعتماد اعتماد کند. آنها را می‌توان ارائه دهندگان اطلاعات قابل اعتماد در نظر گرفت.

اوراکل‌ها

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

دو سناریوی ممکن برای تهیه اطلاعات وجود دارد: اتصال یک قرارداد هوشمند به یک وب‌سایت معتبر که به طور متمرکز نتایج منطبق را ذخیره می‌کند، یا اتصال چندین وب‌سایت و سپس فیلتر کردن اطلاعات در چندین منبع که داده‌های یکسانی را ارائه می‌دهند. برای تأیید صحت اطلاعات، از اوراکل‌هایی مانند Oraclize استفاده می‌شود که از TLSNotary (یک اصلاح TLS برای تأیید اعتبار داده‌ها) استفاده می‌کند. اطلاعات زیادی در مورد Oraclize در گوگل و چندین مقاله در Habr وجود دارد. امروز، من در مورد اوراکل‌هایی که از رویکرد کمی متفاوت برای انتقال اطلاعات استفاده می‌کنند، بحث خواهم کرد: Town Crier و DECO. این مقاله اصول عملیاتی هر دو اوراکل و همچنین مقایسه دقیقی را شرح می‌دهد.

تاون کریر

تاون کریر (TC) توسط IC3 (ابتکار عمل برای ارزهای دیجیتال و قراردادها) در سال ۲۰۱۶ در CCS'16 ارائه شد. ایده اصلی TC انتقال اطلاعات از یک وب‌سایت به یک قرارداد هوشمند و تأیید این است که اطلاعات ارائه شده توسط TC با اطلاعات موجود در وب‌سایت یکسان است. TC از TEE (محیط اجرای مطمئن) برای اطمینان از مالکیت داده‌ها استفاده می‌کند. نسخه اصلی TC کار با Intel SGX را شرح می‌داد.
تاون کریر از یک بخش درون بلاکچین و یک بخش درون خود سیستم عامل - TC Server - تشکیل شده است.

قرارداد TC روی بلاکچین قرار دارد و به عنوان رابط کاربری برای TC عمل می‌کند. این قرارداد درخواست‌ها را از CU (قرارداد هوشمند کاربر) می‌پذیرد و پاسخ‌ها را از سرور TC برمی‌گرداند. سرور TC محل قرارگیری رله است که اتصال enclave را به اینترنت (ترافیک دو طرفه) برقرار می‌کند و enclave را به بلاکچین متصل می‌کند. enclave حاوی progencl است، کدی که درخواست‌ها را از بلاکچین اجرا می‌کند و پیام‌های امضا شده دیجیتالی را به بلاکچین برمی‌گرداند. Progencl شامل بخشی از کد قرارداد هوشمند است و اساساً برخی از عملکردهای آن را انجام می‌دهد.

Enclave اینتل SGX را می‌توان به عنوان یک کتابخانه مشترک با یک API که از طریق ecall عمل می‌کند، در نظر گرفت. Ecall کنترل را به enclave منتقل می‌کند. enclave کد خود را تا زمان خاتمه یا وقوع یک استثنا اجرا می‌کند. Ocallها برای فراخوانی توابع تعریف شده در خارج از enclave استفاده می‌شوند. Ocallها در خارج از enclave اجرا می‌شوند و توسط آن به عنوان فراخوانی‌های ناامن رفتار می‌شوند. پس از اجرای ocall، کنترل به enclave باز می‌گردد.

بخش Enclave یک کانال امن با وب سرور پیکربندی می‌کند، TLS handshake را با سرور هدف انجام می‌دهد و تمام عملیات رمزنگاری را به صورت داخلی مدیریت می‌کند. کتابخانه TLS (mbedTLS) و یک کد HTTP فشرده‌سازی شده به محیط SGX صادر می‌شوند. Enclave همچنین شامل گواهی‌های CA ریشه (مجموعه‌ای از گواهی‌ها) برای تأیید گواهی‌های سرور از راه دور است. کنترل‌کننده درخواست، یک درخواست دیتاگرام را در قالب ارائه شده توسط اتریوم دریافت می‌کند، آن را رمزگشایی و تجزیه می‌کند. سپس یک تراکنش اتریوم حاوی دیتاگرام درخواستی ایجاد می‌کند، آن را با استفاده از skTC امضا می‌کند و آن را به رله ارسال می‌کند.

مؤلفه رله شامل رابط کاربری، TCP و رابط بلاکچین است. رابط کاربری برای تأیید کد enclave و ارتباط با کلاینت استفاده می‌شود. کلاینت با استفاده از ecall یک درخواست تأیید ارسال می‌کند و یک مهر زمانی امضا شده توسط skTC به همراه یک امضای تأیید (att) دریافت می‌کند. سپس امضای تأیید با استفاده از سرویس تأیید اینتل (IAS) تأیید می‌شود و مهر زمانی توسط یک سرویس زمانی قابل اعتماد تأیید می‌شود. رابط بلاکچین درخواست‌های ورودی را تأیید می‌کند و تراکنش‌ها را برای تحویل دیتاگرام روی بلاکچین قرار می‌دهد. Geth کلاینت رسمی اتریوم است و به رله اجازه می‌دهد تا از طریق تماس‌های RPC با بلاکچین تعامل داشته باشد.

با همکاری TEE، TC به چندین enclave اجازه می‌دهد تا به صورت موازی اجرا شوند و در نتیجه سرعت پردازش را سه برابر کنند. در حالی که سرعت با یک enclave واحد ۱۵ تراکنش در ثانیه بود، با اجرای موازی ۲۰ enclave، سرعت به ۶۵ تراکنش در ثانیه افزایش می‌یابد. برای مقایسه، حداکثر سرعت در بلاکچین بیت‌کوین ۲۶ تراکنش در ثانیه است.

DECO

DECO (اوراکل‌های غیرمتمرکز برای TLS) در CCS'20 ارائه شد و با سایت‌هایی که از اتصالات TLS پشتیبانی می‌کنند، کار می‌کند. این فناوری محرمانگی و یکپارچگی داده‌ها را تضمین می‌کند.
DECO با TLS از رمزگذاری متقارن استفاده می‌کند، به این معنی که کلاینت و وب سرور هر دو کلیدهای رمزگذاری را به اشتراک می‌گذارند و به کلاینت اجازه می‌دهند در صورت تمایل داده‌های جلسه TLS را جعل کند. برای حل این مشکل، DECO از یک پروتکل دست‌دهی سه‌جانبه بین اثبات‌کننده (قرارداد هوشمند)، تأییدکننده (اوراکل) و وب سرور (منبع داده) استفاده می‌کند.

اصل DECO این است که یک اثبات‌کننده، داده‌ای از نوع D را دریافت می‌کند و به یک تأییدکننده تأیید می‌کند که D از یک سرور TLS به نام S آمده است. مشکل دیگر این است که TLS داده‌ها را امضا نمی‌کند و این امر اثبات اینکه داده‌ها از سرور صحیح آمده‌اند را برای یک کلاینت TLS دشوار می‌کند (مشکل منشأ).

پروتکل DECO از کلیدهای رمزگذاری KENc و KMac استفاده می‌کند. کلاینت درخواست Q را به وب سرورپاسخ از سرور R به صورت رمزگذاری شده می‌رسد، اما کلاینت و سرور KMac یکسانی را به اشتراک می‌گذارند و کلاینت می‌تواند پیام TLS را جعل کند. راه حل DECO این است که KMac را از کلاینت (اثبات‌کننده) تا زمانی که به درخواست پاسخ دهد، "مخفی" کند. اکنون KMac بین اثبات‌کننده و تأییدکننده - KpMac و KvMac - تقسیم می‌شود. سرور KMac را برای رمزگذاری پاسخ با استفاده از عملیات تقسیم کلید KpMac ⊕ KvMac = KMac دریافت می‌کند.

با تنظیم یک ارتباط سه‌جانبه (three-way handshake)، تبادل داده‌ها بین کلاینت و سرور با تضمین امنیت انجام خواهد شد.

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

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

حملات به اوراکل‌ها

از دیدگاه امنیت اطلاعات، حملات زیر به Town Crier در نظر گرفته شد:

تزریق کد مخرب تماس هوشمند روی گره‌های TEE.
این حمله شامل ارسال عمدی یک کد قرارداد هوشمند نامعتبر به TEE است. این به مهاجمی که به گره دسترسی پیدا می‌کند اجازه می‌دهد تا قرارداد هوشمند (کلاهبرداری) خود را روی داده‌های رمزگشایی شده اجرا کند. با این حال، مقادیر برگشتی با یک کلید خصوصی رمزگذاری می‌شوند و تنها راه دسترسی به چنین داده‌هایی، افشای متن رمز شده هنگام بازگشت/برداشت است.
دفاع در برابر این حمله شامل تأیید صحت کد موجود در آدرس فعلی توسط enclave است. این امر می‌تواند با استفاده از یک طرح آدرس‌دهی که در آن آدرس قرارداد با هش کردن کد قرارداد تعیین می‌شود، محقق شود.
نشت تغییرات متن رمزنگاری‌شده‌ی وضعیت قرارداد.
ماهیت حمله: مالکان گره‌هایی که قراردادهای هوشمند را اجرا می‌کنند، به وضعیت قرارداد به صورت رمزگذاری شده در خارج از محدوده دسترسی دارند. یک مهاجم، با به دست گرفتن کنترل یک گره، می‌تواند وضعیت تماس را قبل و بعد از یک تراکنش مقایسه کند و مشخص کند که کدام آرگومان‌ها وارد شده و از کدام روش قرارداد هوشمند استفاده شده است، زیرا کد قرارداد هوشمند و مشخصات فنی آن به صورت عمومی در دسترس است.
محافظت در تضمین قابلیت اطمینان خود واحد.
حملات کانال جانبی
نوع خاصی از حمله که از نظارت بر حافظه enclave و دسترسی به حافظه پنهان در سناریوهای مختلف استفاده می‌کند. نمونه‌ای از چنین حمله‌ای Prime and Probe است.

دستور حمله:
- t0: مهاجم کل حافظه پنهان داده فرآیند قربانی را پر می‌کند.
- t1: قربانی کدی را با دسترسی‌های حافظه‌ای که به داده‌های حساس قربانی (کلیدهای رمزنگاری) بستگی دارد، اجرا می‌کند. خط حافظه پنهان بر اساس مقدار بیت کلید انتخاب می‌شود. در مثال شکل، بیت کلید 0 است و آدرس X از خط 2 حافظه پنهان خوانده می‌شود. داده‌های ذخیره شده در X در حافظه پنهان بارگذاری می‌شوند و داده‌هایی را که قبلاً در آنجا بودند، جایگزین می‌کنند.
- t2: مهاجم بررسی می‌کند که کدام یک از خطوط حافظه پنهان او - خطوطی که توسط قربانی استفاده شده است - حذف شده‌اند. این کار با اندازه‌گیری زمان دسترسی انجام می‌شود. با تکرار این عملیات برای هر بیت کلید، مهاجم کل کلید را به دست می‌آورد.

محافظت در برابر حمله: Intel SGX دارای محافظت در برابر حملات کانال جانبی است که مانع از نظارت بر رویدادهای مرتبط با حافظه پنهان می‌شود، اما یک حمله Prime و Probe همچنان موفق خواهد بود زیرا مهاجم رویدادهای حافظه پنهان فرآیند خود را رصد می‌کند و حافظه پنهان را با قربانی به اشتراک می‌گذارد.

بنابراین، در حال حاضر هیچ محافظت قابل اعتمادی در برابر این حمله وجود ندارد.

حملات Spectre و Foreshadow (L1TF)، مشابه Prime و Probe، نیز شناخته شده‌اند. آن‌ها اجازه می‌دهند داده‌ها از طریق یک کانال جانبی از حافظه نهان خوانده شوند. یک راهکار مقابله با آسیب‌پذیری Spectre-v2 در دسترس است که هر دوی این حملات را خنثی می‌کند.

در رابطه با DECO، روش دست‌دهی سه‌جانبه تضمین امنیتی را فراهم می‌کند:

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

در DECO، فقط آسیب‌پذیری‌های تزریق ترافیک امکان‌پذیر است. در ابتدا، در طول یک دست‌دهی سه‌جانبه، تأییدکننده می‌تواند هویت سرور را با استفاده از یک نانس جدید ایجاد کند. با این حال، پس از دست‌دهی، تأییدکننده باید به شاخص‌های لایه شبکه (آدرس های IPبنابراین، اتصال بین تأییدکننده و سرور باید از تزریق ترافیک محافظت شود. این امر با استفاده از یک پروکسی محقق می‌شود.

مقایسه اوراکل‌ها

تاون کریر به یک محدوده‌ی سمت سرور متکی است، در حالی که دکو (DECO) با استفاده از یک دست‌دهی سه‌طرفه و رمزگذاری با کلیدهای رمزنگاری، احراز هویت مبدا داده‌ها را امکان‌پذیر می‌کند. این اوراکل‌ها بر اساس معیارهای زیر مقایسه شدند: عملکرد، امنیت، هزینه و کاربردی بودن.

تاون کریر
DECO

عملکرد
سریع‌تر (۰.۶ ثانیه برای اتمام)
کندتر (۱۰.۵۰ ثانیه برای اتمام پروتکل)

امنیت
امنیت کمتر
امن تر

هزینه
گران تر
ارزان تر

عملی بودن
نیاز به سخت‌افزار مخصوص
با هر سروری که از TLS پشتیبانی کند، کار می‌کند.

عملکردDECO به یک دست‌دهی سه‌طرفه نیاز دارد که تکمیل آن از طریق LAN، 0.37 ثانیه طول می‌کشد. 2PC-HMAC برای ارتباط پس از اتصال مؤثر است (0,13 ثانیه برای هر نوشتن). عملکرد DECO به مجموعه‌های رمزنگاری TLS موجود، اندازه داده‌های خصوصی و پیچیدگی اثبات‌ها برای یک کاربرد خاص بستگی دارد. با استفاده از برنامه گزینه‌های دودویی IC3 به عنوان مثال، تکمیل پروتکل از طریق LAN تقریباً 10,50 ثانیه طول می‌کشد. برای مقایسه، Town Crier تقریباً 0,6 ثانیه طول می‌کشد تا همان کاربرد را تکمیل کند، که آن را تقریباً 20 برابر سریع‌تر از DECO می‌کند. در صورت برابر بودن سایر شرایط، TC سریع‌تر خواهد بود.

امنیتحملات کانال جانبی به محدوده Intel SGX مؤثر هستند و می‌توانند آسیب واقعی به شرکت‌کنندگان قرارداد هوشمند وارد کنند. حملات تزریق ترافیک با DECO امکان‌پذیر است، اما استفاده از پروکسی این حملات را کاهش می‌دهد. بنابراین، DECO امن‌تر است.

هزینههزینه سخت‌افزاری که از Intel SGX پشتیبانی می‌کند، بیشتر از هزینه راه‌اندازی پروتکل در DECO است. بنابراین، TC گران‌تر است.

عملی بودنکار با Town Crier نیاز به سخت‌افزار تخصصی دارد که از TEE پشتیبانی کند. به عنوان مثال، Intel SGX در پردازنده‌های نسل ششم Intel Core و بالاتر پشتیبانی می‌شود. از سوی دیگر، DECO از هر سخت‌افزاری پشتیبانی می‌کند، اگرچه پیکربندی DECO وجود دارد که از TEE استفاده می‌کند. اگرچه راه‌اندازی دست‌دهی سه‌طرفه با DECO می‌تواند مدتی طول بکشد، اما این در مقایسه با محدودیت‌های سخت‌افزاری Town Crier ناچیز است و DECO را کاربردی‌تر می‌کند.

نتیجه

پس از بررسی جداگانه دو اوراکل و مقایسه آنها بر اساس چهار معیار، مشخص است که Town Crier در سه مورد از چهار معیار، نسبت به DECO در سطح پایین‌تری قرار دارد. DECO امن‌تر، ارزان‌تر و کاربردی‌تر است، اگرچه راه‌اندازی یک پروتکل سه‌جانبه می‌تواند مدتی طول بکشد و دارای معایبی مانند عملیات اضافی با کلیدهای رمزگذاری است. TC سریع‌تر از DECO است، اما آسیب‌پذیری مرتبط با حمله کانال جانبی، آن را مستعد خطرات حریم خصوصی می‌کند. توجه به این نکته مهم است که DECO در ژانویه ۲۰۲۰ معرفی شد، بنابراین زمان کافی برای ایمن در نظر گرفتن آن نگذشته است. Town Crier به مدت چهار سال مورد حمله قرار گرفته و ممیزی‌های متعددی را پشت سر گذاشته است، بنابراین استفاده از آن در بسیاری از پروژه‌ها توجیه‌پذیر است.

منبع: www.habr.com