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

در اوایل سال جاری ، ما یک برنامه buff bounty را راه اندازی کردیم که بر یافتن مسائلی در مشخصات زنجیره چراغ و/یا پیاده سازی مشتری (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 بود. اولین مورد روی مشتری Prysm تأثیر گذاشت.

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

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

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

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

در حال بسته شدن

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

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