شماره ایمن 1 | وبلاگ بنیاد اتریوم

در اوایل سال جاری، ما راه اندازی شد برنامه جایزه باگ تمرکز بر یافتن مسائل در مشخصات زنجیره فانوس دریایی، و/یا در پیاده سازی های مشتری (Lighthouse، Nimbus، Teku، Prysm و غیره). نتایج (و گزارش‌های آسیب‌پذیری) و همچنین درس‌هایی که هنگام اصلاح مشکلات بالقوه آموخته‌اند، روشن‌کننده بوده‌اند.

در این سری جدید، هدف ما بررسی و به اشتراک گذاشتن برخی از بینش‌هایی است که از کارهای امنیتی تا به امروز و با حرکت رو به جلو به دست آورده‌ایم.

این پست اول برخی از موارد ارسالی را که به طور خاص BLS اولیه را هدف قرار می دهند، تجزیه و تحلیل می کند.

سلب مسئولیت: تمام اشکالات ذکر شده در این پست قبلاً رفع شده است.

BLS همه جا هست

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

در اینجا ما در سال 2021 هستیم و جفت‌ها یکی از بازیگران اصلی بسیاری از رمزنگاری‌های اولیه مورد استفاده در فضای بلاک چین (و فراتر از آن) هستند: BLS امضاهای کل، سیستم های ZK-SNARKS و غیره

کار توسعه و استانداردسازی مربوط به امضاهای BLS مدتی است که یک پروژه در حال انجام برای محققان EF بوده است که بخشی از آن توسط جاستین دریک و خلاصه در پست اخیر او در reddit.

جدیدترین و بهترین

در این بین، به روز رسانی های زیادی وجود داشته است. BLS12-381 در حال حاضر به عنوان جهانی شناخته شده است منحنی جفت شدن مورد استفاده قرار گیرد با توجه به دانش فعلی ما.

سه پیش نویس مختلف IRTF در حال حاضر در دست توسعه هستند:

1. منحنی های دوستدار جفت
2. امضاهای BLS
3. هش کردن به منحنی های بیضوی

علاوه بر این، مشخصات زنجیره فانوس دریایی بالغ شده است و قبلاً تا حدی مستقر شده است. همانطور که در بالا اشاره شد، امضاهای BLS بخش مهمی از پازل پشت اثبات سهام (PoS) و زنجیره بیکن هستند.

درس های اخیر آموخته شده است

پس از جمع‌آوری موارد ارسالی با هدف قرار دادن اولیه‌های BLS مورد استفاده در لایه اجماع، می‌توانیم باگ‌های گزارش‌شده را به سه بخش تقسیم کنیم:

• نظارت بر پیش نویس IRTF
• اشتباهات اجرایی
• نقض اجرای پیش نویس IRTF

بیایید در هر بخش بزرگنمایی کنیم.

نظارت بر پیش نویس IRTF

یکی از خبرنگاران، (نگوین توی مین کوان، اختلافاتی را در پیش نویس IRTF، و دو مقاله سفید با یافته ها منتشر کرد:

در حالی که تناقضات خاص هنوز موضوعیت دارند برای بحث، او چیزهای جالبی یافت پیاده سازی مسائل در حین انجام تحقیقات خود

اشتباهات اجرایی

گیدو ورانکن توانست چندین مسئله “کوچک” را در آن کشف کند BLST استفاده کردن فاز دیفرانسیل. نمونه هایی از موارد زیر را ببینید:

او این را با کشف یک آسیب‌پذیری متوسط ​​که بر روی آن تأثیر می‌گذارد، تکمیل کرد تابع blst_fp_eucl_inverse BLST.

نقض اجرای پیش نویس IRTF

دسته سوم اشکال مربوط به نقض اجرای پیش نویس IRTF بود. اولین مورد تاثیر گذاشت مشتری پریسم.

برای توصیف این موضوع ابتدا باید کمی پیش زمینه ارائه دهیم. را امضاهای BLS پیش نویس IRTF شامل 3 طرح است:

1. طرح اساسی
2. افزایش پیام
3. اثبات مالکیت

را مشتری پریسم هیچ تمایزی بین 3 در API خود قائل نمی شود، که در بین پیاده سازی ها منحصر به فرد است (مثلاً py_ecc). یک ویژگی در مورد طرح اساسی است نقل قول به کلمه: “این تابع ابتدا تضمین می کند که همه پیام ها متمایز هستند” . این امر در AggregateVerify عملکرد. Prysm این اختلاف را توسط منسوخ کردن استفاده از AggregateVerify (که در هیچ کجای مشخصات زنجیره بیکن استفاده نمی شود).

موضوع دوم تاثیر گذاشت py_ecc. در این مورد، روند سریال سازی شرح داده شده در مشخصات ZCash BLS12-381 که اعداد صحیح را همیشه در محدوده قرار می دهد [0, p – 1]. را py_ecc اجرای این بررسی را برای گروه G2 از BLS12-381 فقط برای بخش واقعی اما عملیات مدول را برای قسمت خیالی. مشکل با درخواست کشش زیر برطرف شد: اعتبار سنجی ناکافی در decompress_G2 Deserialization در py_ecc.

بسته شدن

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

ما به شدت تشویق کردن شما کمک می کند تا اطمینان حاصل شود که لایه اجماع به رشد ایمن تر در طول زمان ادامه می دهد. با آن، ما مشتاقانه منتظر شنیدن نظرات شما هستیم و شما را به DIG تشویق می کنیم! اگر فکر می‌کنید یک آسیب‌پذیری امنیتی یا هر باگ مربوط به زنجیره beacon یا مشتریان مرتبط پیدا کرده‌اید، گزارش اشکال ارسال کنید! 💜🦄