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

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

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

اوراکلز

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

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

تاون کریر

Town Crier (TC) توسط IC3 (The Initiative for Cryptocurrency and Contracts) در سال 2016 در CCS'16 معرفی شد. ایده اصلی TC: انتقال اطلاعات از یک وب سایت به یک قرارداد هوشمند و اطمینان از اینکه اطلاعات ارائه شده توسط TC مانند وب سایت است. TC از TEE (محیط اجرای مطمئن) برای احراز هویت مالکیت داده استفاده می کند. نسخه اصلی TC نحوه کار با Intel SGX را شرح می دهد.
Town Crier از بخشی در داخل بلاک چین و بخشی در داخل خود سیستم عامل - TC Server تشکیل شده است.

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

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

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

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

کار با TEE، TC به شما این امکان را می دهد که چندین انکلاو را به صورت موازی اجرا کنید و در نتیجه سرعت پردازش اطلاعات را 3 برابر افزایش دهید. اگر با یک محصور در حال اجرا سرعت 15 tx/sec بود، با 20 tx/sec سرعت سرعت به 65 tx/sec افزایش می‌یابد؛ برای مقایسه، حداکثر سرعت عملیاتی در بلاک چین بیت‌کوین 26 tx/sec است.

DECO

DECO (Oracles غیرمتمرکز برای 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 دریافت می کند.

با راه اندازی دست دادن سه طرفه، تبادل اطلاعات بین مشتری و سرور با تضمین امنیت انجام می شود.

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

Chainlink قصد دارد یک PoC DECO اولیه را با تمرکز بر برنامه های مالی غیرمتمرکز مانند Mixicles انجام دهد. در زمان نگارش این مقاله، خبری در فوربس منتشر شد مبنی بر اینکه Chainlink DECO را از دانشگاه کرنل خریداری کرده است.

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

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

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

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

3. حملات کانال جانبی
   نوع خاصی از حمله که از نظارت بر حافظه محصور و دسترسی کش در سناریوهای مختلف استفاده می کند. نمونه ای از چنین حمله ای Prime و Probe هستند.
   
   دستور حمله:

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

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

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

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

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

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

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

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

Town Crier مبتنی بر کار با یک Enclave در بخش سرور است، در حالی که DECO به شما امکان می دهد با استفاده از یک دست دادن سه طرفه و رمزگذاری داده ها با کلیدهای رمزنگاری، صحت منشاء داده ها را تأیید کنید. مقایسه این اوراکل ها بر اساس معیارهای زیر انجام شد: عملکرد، امنیت، هزینه و عملی.

تاون کریر
DECO

کارایی
سریعتر (0.6 ثانیه تا پایان)
کندتر (10.50 ثانیه تا پایان پروتکل)

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

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

عملی بودن
نیاز به سخت افزار خاصی دارد
با هر سروری که از 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 در خانواده پردازنده های نسل ششم اینتل Core به بعد پشتیبانی می شود. DECO به شما امکان می دهد با هر تجهیزاتی کار کنید، اگرچه تنظیمات DECO با استفاده از TEE وجود دارد. با توجه به فرآیند راه اندازی، دست دادن سه طرفه DECO ممکن است کمی طول بکشد، اما این در مقایسه با محدودیت سخت افزاری TC چیزی نیست، بنابراین DECO عملی تر است.

نتیجه

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

منبع: www.habr.com