مقدمه

در ژوئیه ۲۰۲۱، نیم یک بررسی دقیق امنیتی توسط ژان-فیلیپ آومسون، یک متخصص امنیت مشهور، انجام داد. هدف شناسایی آسیب‌پذیری‌ها و نقص‌های بالقوه در کدپایه Nym بود که بر روی رمزنگاری، امنیت کد و امنیت پروتکل تمرکز داشت. بررسی‌ها به دنبال اطمینان از یکپارچگی و استحکام سیستم بود و جنبه‌های کلیدی معماری و پیاده‌سازی آن را پوشش می‌داد. شما می‌توانید گزارش کامل حسابرسی را اینجا مشاهده کنید.

خلاصه‌ی ممیزی

این ممیزی در تابستان ۲۰۲۱ انجام شد. دامنه ممیزی شامل چندین ریپازیتوری از پروژه Nym بود، که شامل:

• ریپازیتوری اصلی نیم: nymtech/nym، که سرویس‌های میکس‌نود، gateway و اعتبارسنج را پیاده‌سازی می‌کند.
• پیکربندی بسته میکس‌نت اسفینکس: nymtech/sphinx که توسط میکس‌نودها استفاده می‌شود.
• پروتکل امضای آستانه نارگیل: nymtech/coconut، که برای صدور اعتبار استفاده می‌شود.

این ممیزی شامل بازبینی آخرین نسخه کد در شاخه develop بود، که به دلیل تکامل سریع پروژه به‌طور مرتب به‌روز می‌شد. Nym دسترسی کامل به کدبیس، مشخصات دقیق پروژه، مقالات پژوهشی و مستندات پشتیبان را در اختیار ژان-فیلیپ اومَسون قرار داد.

حوزه‌های کلیدی تمرکز ممیزی

ممیزی بر سه حوزه اصلی متمرکز بود: امنیت کد، رمزنگاری، و طراحی پروتکل. ممیزی‌ها کدبیس Nym را به‌طور کامل بررسی کردند تا آسیب‌پذیری‌ها را شناسایی کنند و به دنبال مشکلات رایجی مانند الگوهای ناامن کدنویسی و خطاهای حل نشده بودند. توجه ویژه‌ای به ایمنی حافظه (memory safety) و اجتناب از مشکلاتی مانند سرریز عدد صحیح (integer overflows) معطوف شد.

بازنگری رمزنگاری طیف وسیعی از هسته‌های اصلی مورد استفاده توسط Nym را شامل می‌شد، مانند AES-128-CTR، BLAKE2b، ChaCha، Ed25519 و دیگران. هدف، اطمینان از پیاده‌سازی صحیح این الگوریتم‌ها و بررسی مقاومت آنها در برابر حملات side-channel، استفاده نادرست از پارامترها، و نقص در randomness generation بود.

ممیزی علاوه بر بازبینی اجزای منفرد، پروتکل‌هایی را که عملکرد اصلی Nym را تعریف می‌کنند را نیز مورد بررسی قرار داد. این شامل بررسی [قالب بسته Sphinx] (https://nym.com/blog/sphinx-the-anonymous-data-format-behind-lightning-and-nym) و پروتکل Coconut threshold blind signature برای شناسایی کردن هرگونه ضعف که می‌توانست حریم خصوصی یا امنیت را به خطر بیندازد. تمرکز بازبینی بر نشت احتمالی اطلاعات بود که تهدیدی برای ناشناسی کاربران است، همچنین آسیب‌پذیری‌هایی مانند دور زدن MAC verification، حملات small subgroup، و نقص در عملیات رمزنگاری مانند محاسبات BLS12-381 و zero-knowledge proofs در دستور کار خود داشت.

مروری بر یافته‌ها

در طول ممیزی، ۹ آسیب‌پذیری امنیتی کشف شد. هیچ‌کدام در سطح بحرانی نبودند، دو مورد در سطح خطربالا، یک مورد در سطح خطرمتوسط، و شش مورد در سطح خطرپایین رتبه‌بندی شدند. علاوه بر این، ۱۷ مشاهده دیگر ثبت شد که توصیه‌هایی برای تقویت بیشتر شبکه Nym ارائه دادند. در ادامه، یک مرور کلی از اصلاحات اعمال شده برای رفع تمامی آسیب‌پذیری‌های امنیتی شناسایی‌شده، ارائه می‌کنیم.

S-SPHX-01: اعتبارسنجی‌های مفقودی کلیدها (Missing validations of keys) – سطح خطرپایین

مشکل شناسایی‌شده در nymtech/sphinx مربوط به اعتبارسنجی ناکافی کلیدهای خصوصی و عمومی با مهاجرت به کتابخانه x25519 برطرف شد، چرا که این کتابخانه به‌طور ذاتی اعتبار کلیدها را از طریق طراحی خود اعمال می‌کند. پیاده‌سازی x25519 تضمین می‌کند که کلیدهای خصوصی به‌درستی clamped می‌شوند، به این معنا که آنها به‌طور خودکار به یک زیرمجموعه معتبر از scalars محدود می‌شوند و خطر استفاده از کلیدهای خصوصی نامعتبر از بین می‌رود. علاوه بر این، درحالی‌که x25519 به‌طور صریح کلیدهای عمومی را اعتبارسنجی نمی‌کند، پیاده‌سازی Montgomery ladder آن به‌طور طبیعی مانع استفاده از برخی نقاط نامعتبر منحنی می‌شود. این امر خطر مواجهه با نقاط در بی‌نهایت یا سایر کلیدهای عمومی معیوب را کاهش می‌دهد. همچنین، فرآیند تبادل کلید، تضمین می‌کند که یک shared secret تمام-صفر در صورت لزوم قابل شناسایی و رد شدن است. با استفاده از x25519، ما اعتبارسنجی کلیدها را به‌طور چشمگیری بهبود بخشیدیم و خطر استفاده از کلیدهای نامعتبر یا با فرمت اشتباه در سیستم را کاهش دادیم. این موضوع نگرانی‌های مطرح‌شده در ممیزی را در مورد اعتبارسنجی کلیدها، به‌طور چشمگیری برطرف می‌کند.

S-COCO-01: توزیع بایاس در Hash-to-scalar (Hash-to-scalar biased distribution) – سطح خطر پایین

فرآیند hashing برای استخراج یک scalar در میدان BLS12-381 قبلاً شامل نگاشت خروجی یک تابع hash مستقیماً به یک عنصر میدان scalar بود. با این حال، این رویکرد به دلیل عملیات کاهش پیمانه‌ای (mod p) باعث بایاس می‌شد، چرا که زمانی که خروجی hash دقیقاً با عدد اول پیمانه میدان هم‌راستا نبود، توزیع غیر یکنواختی ایجاد می‌شد. برای رفع این مشکل، ما تابع hash-to-scalar موجود را با تابع hash_to_field از crate مربوط به bls12_381 جایگزین کردیم. این تابع از مشخصات استاندارد hash-to-field پیروی می‌کند و نگاشت یکنواخت و بدون بایاس خروجی‌های hash به عناصر میدان را تضمین می‌کند. علاوه بر این، پروتکل zk-Nym که جایگزین Coconut شد نیز به این تابع برای عملیات hashing خود متکی است و بدین ترتیب سازگاری و درستی محاسبات رمزنگاری تضمین می‌شود.

S-COCO-02: مجوزهای فایل‌های کلید keygen-cli (keygen-cli key files permissions) – سطح خطر پایین

ممیزی‌ها اشاره کردند که فایل‌های کلید keygen-cli دارای مجوزهای پیش‌فرض هستند، درحالی‌که برای امنیت بهتر باید محدودتر می‌بودند. این مسئله نیازی به تغییر نداشت، زیرا keygen-cli تنها در مراحل اولیه پیاده‌سازی Coconut استفاده شده بود. این بخش دیگر جزو ریپازیتوری اصلی Nym نیست و به‌طور فعال مورد استفاده قرار نمی‌گیرد. از آنجایی که این ابزار منسوخ شد، اقدام بیشتری در مورد مجوزهای فایل‌های آن لازم نبود.

S-CRYP-01: احتمال استفاده مجدد از IV در Stream Cipher (Potential stream cipher IV reuse) – سطح خطر بالا

این مشکل مربوط به تابعی بود که داده‌ها را با استفاده از یک initialization vector (IV) رمزگذاری می‌کرد. اگر IV ارائه نمی‌شد، تابع به‌طور پیش‌فرض از یک IV صفر استفاده می‌کرد که می‌توانست منجر به استفاده مجدد IV شود. این مشکل با معرفی پروتکل AES-GCM-SIV در مرحله ثبت‌نام برطرف شد. برای جلوگیری از حملات downgrade، گزینه استفاده از کلید قدیمی AES-128-CTR برای ارتباط بین کلاینت و gateway حذف شد. تا زمانی که هم کلاینت و هم gateway به‌روز باشند، آنها همیشه یک IV تصادفی و غیر صفر تولید می‌کنند.

S-PROT-01: احتمال دوبار خرج کردن credentials (Potential double spend of credentials) – سطح خطر بالا

ممیزی‌ها متوجه شدند نسخه بررسی‌شده Coconut مکانیزم شناسایی دوبار خرج کردن را نداشت، که می‌توانست باعث شود چندین gateway به اشتباه یک credential را به‌طور هم‌زمان به‌عنوان استفاده‌نشده، تأیید کنند. با این حال، قرارداد Coconut bandwidth بعداً به‌روزرسانی شد تا استفاده از credential را با ذخیره‌سازی state در بلاک‌چین ردیابی کند و این مشکل را برطرف کند. علاوه بر این، Coconut از آن زمان با پروتکل zk-nyms جایگزین شده است که شامل قابلیت شناسایی دوبار خرج کردن به‌طور داخلی می‌باشد.

S-NYM-01: وابستگی‌ها با آسیب‌پذیری‌های شناخته‌شده سطح خطر متوسط

بازرسان شناسایی کردند که چندین مؤلفه در پروژه Nym به نسخه‌هایی قدیمی‌ای متکی بودند که با آسیب‌پذیری‌های امنیتی شناخته‌شده بوده‌اند. برای مثال، ریپازیتوری Sphinx از یک نسخه ناامن از crate مربوط به generic-array استفاده می‌کرد، ریپازیتوری اصلی Nym به یک نسخه قدیمی از tokio متکی بود، و کلاینت Nym شامل چندین crate با مشکلات امنیتی شناخته‌شده بود که برخی از آن‌ها به نظر می‌رسید قابل بهره‌برداری در زمینه Nym باشند. در پی توصیه بازرسان، ما وابستگی‌ها را به‌طور منظم به‌روزرسانی کردیم. اکنون وابستگی‌هایمان را به‌طور فعال از طریق Dependabot مدیریت می‌کنیم که به‌صورت مداوم نظارت کرده و بسته‌های قدیمی یا آسیب‌پذیر را به‌طور خودکار در مخازن ما شناسایی می‌کند. اصلاحات اعمال‌شده توسط Dependabot را می‌توان به‌طور مستمر در ریپازیتوری ما مشاهده کرد.

S-NYM-02: خطای رمزگشایی مدیریت نشده سطح خطر پایین

مشکل شناسایی‌شده در کد در تابع recover_identifier در مسیر nym/common/nymsphinx/acknowledgments/identifier.rs رخ می‌دهد، جایی که خطاهای رمزگشایی، مانند پارامترهای نامعتبر، به درستی مدیریت نمی‌شوند. این موضوع می‌تواند منجر به panic یا سایر وضعیت‌های ناامن شود. مشکل مشابهی در تابع recover_plaintext در مسیر nym/common/nymsphinx/src/receiver.rs وجود دارد. مدیریت‌نکردن خطاهای رمزگشایی می‌تواند به‌طور بالقوه باعث شود سیستم وارد یک وضعیت ناپایدار یا ناامن گردد. پس از بررسی دقیق توابع، ما نتیجه گرفتیم که نمونه اول ارائه‌شده، در recover_identifier، اساساً مسئله‌ای نیست. ارائه پارامترهای نادرست غیرممکن است، زیرا همه چیز با AckEncryptionAlgorithm (لینک) پارامترگذاری شده است، به این معنا که هر مقدار نامعتبر در زمان کامپایل شناسایی خواهد شد. مورد دوم ذکرشده، recover_plaintext، دیگر وجود ندارد. با این حال، کدی که جایگزین آن شد، recover_plaintext_from_regular_packet، در صورت تغییر برخی پارامترها به مقادیر غیرمعمول، دارای یک حالت شکست نظری بود. ما این موضوع را با افزودن مدیریت مناسب خطا برطرف کردیم تا اطمینان حاصل شود سیستم حتی در حالت‌های لبه‌ای (edge cases) پایدار باقی بماند.

S-NYM-03: Panic در تولید شناسه‌های قطعه سطح خطر پایین

کدی که برای تولید شناسه‌های جدید قطعه استفاده می‌شود، به‌طور تصادفی یک مقدار i32 را انتخاب کرده و قدر مطلق آن را می‌گیرد. با این حال، این رویکرد می‌تواند منجر به panic در مواردی شود که مقدار تصادفی انتخاب‌شده برابر با i32::MIN باشد، زیرا قدر مطلق آن نمی‌تواند در محدوده i32 نمایش داده شود. این امر به دلیل محدودیت‌های کدگذاری 2-complement منجر به خطای "attempt to negate with overflow" می‌شود. ما موافقیم که شدت این مشکل بسیار پایین ارزیابی شده است، زیرا احتمال وقوع این حالت تقریباً ۱ در ۴ میلیارد است. با این وجود، ما این مشکل را با اجرای اصلاح پیشنهادی بازرس برطرف کرده‌ایم تا از panic و خرابی‌های غیرمنتظره جلوگیری شود، به‌ویژه زمانی که میلیون‌ها کاربر هزاران قطعه شناسه تولید می‌کنند.

S-NYM-04: Mnemonic صفرنشده سطح خطر پایین

مشکل شناسایی‌شده نشان داد که mnemonic مربوط به BIP39 که برای اتصال به سرویس nymd استفاده می‌شد، پس از استفاده صفر (zeroize) نمی‌شد، که باعث باقی‌ماندن چندین نسخه از mnemonic در حافظه می‌گردید. این موضوع خطر افشاء را افزایش می‌داد، زیرا mnemonicها در حافظه به‌طور قابل‌تشخیص‌تر از کلیدهای رمزنگاری خام هستند. برای رفع این مشکل، ما چندین اقدام اصلاحی انجام دادیم. در مؤلفه‌های Rust، crate مربوط به zeroize را یکپارچه کردیم تا اطمینان حاصل شود هر حافظه‌ای که شامل mnemonic است به محض خارج شدن از محدوده به‌طور امن پاک می‌شود. از آنجایی که JavaScript یک زبان garbage-collected است و کنترل مستقیم بر پاک‌سازی حافظه نمی‌دهد، ما رویکرد متفاوتی برای کاهش افشاء در محیط اجرای JavaScript اتخاذ کردیم. به‌طور خاص، سیستم را طوری تغییر دادیم که اجرای JavaScript بلافاصله پس از ارسال mnemonic به لایه Rust متوقف شود. این امر تضمین می‌کند که همه نمونه‌های mnemonic در حافظه JavaScript هنگام خاموش‌شدن محیط اجرا پاک شوند. Mnemonic در اسرع وقت به Rust منتقل می‌شود و قرار گرفتن آن در معرض JavaScript کاهش می‌یابد. در محیط راست(Rust)، crate مربوط به zeroize تضمین می‌کند که همه نمونه‌های mnemonic پس از عدم نیاز، به‌طور امن پاک شوند. با این تغییرات، ما حضور mnemonic در حافظه را به‌طور قابل توجهی به حداقل رسانده‌ایم، خطر افشاء را کاهش داده و اطمینان حاصل کرده‌ایم که داده‌های حساس به‌طور امن مدیریت و پاک می‌شوند.

کلام آخر

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