EN
→ بازگشت به خبرخوان
شمارهٔ ۰۴۰۷Chain Fusion۲ دقیقه۲ منبع

نسخه ۰.۵.۲ Chain Fusion Signer پیش از مشتق‌سازی کلید، مرز ورودی را سخت‌گیرانه‌تر می‌کند

آخرین نسخه Chain Fusion Signer درخواست‌های بیش‌ازحد بزرگِ کلید عمومی را رد می‌کند و ورودی‌های مشتق‌سازی را محدود می‌سازد؛ در نتیجه دو پارامتر معمولی API به کنترل‌های امنیتی صریح برای توسعه‌دهندگان ICP تبدیل می‌شوند.

نسخه ۰.۵.۲ Chain Fusion Signer پیش از مشتق‌سازی کلید، مرز ورودی را سخت‌گیرانه‌تر می‌کند
تصویر: تولید هوش مصنوعی

آخرین نسخه Chain Fusion Signer، یعنی v0.5.2، بیش از آن‌که زنجیره جدیدی اضافه کند، بر محدود کردن داده‌هایی تمرکز دارد که پیش از رسیدن به منطق مشتق‌سازی کلید پذیرفته می‌شوند. این نسخه در ۱۶ سپتامبر منتشر شد و درخواست‌های ورودیِ بیش‌ازحد بزرگ را برای متدهای کلید عمومی با هزینه ثابت رد می‌کند؛ همچنین طول یا دامنه مسیر مشتق‌سازی و نام کلیدی را که signer ارسال می‌کند محدود می‌سازد.

اهمیت این تغییر در آن است که یک سرویس عمومی امضای تراکنش، پیش از آن‌که صرفاً یک قابلیت رمزنگاری باشد، یک مرز پردازش ورودی است. Chain Fusion Signer یک کانستر عمومی و تحت کنترل حاکمیتی است که APIهای ECDSA و Schnorr آستانه‌ای ICP را مستقیماً در اختیار برنامه‌های وب و کاربران CLI می‌گذارد. مستندات آن می‌گویند تماس‌ها از طریق تأییدیه ICRC-2 برای برداشت cycles هزینه دارند و مشتق‌سازی آدرس، چون مواد محرمانه کلید را آشکار نمی‌کند، می‌تواند به‌صورت آفلاین انجام شود.

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

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

برای سازندگان ICP، درس عملی این است که با signer مانند یک مرز امنیتیِ نوع‌دار رفتار کنند، نه یک تابع راه دور عمومی. کد سمت کاربر باید مسیرهای مشتق‌سازی و نام کلید را پیش از تماس اعتبارسنجی کند، رد شدن درخواست را یک پاسخ عادی بداند و نسخه signer و فرض‌های رابط مورد استفاده در تولید را ثابت نگه دارد. این نسخه مسیر تحویل نرم‌افزار را نیز تقویت می‌کند: پیکربندی staging را هنگام ارتقا حفظ می‌کند، از چاپ PIN مربوط به HSM در اسکریپت‌های پیشنهاد جلوگیری می‌کند، روش بررسی آرگومان ارتقا را توضیح می‌دهد، نسخه Internet Identity مورد استفاده در استقرار را ثابت می‌کند و در هر push ممیزی را دوباره اجرا می‌کند.

پیام گسترده‌تر برای Chain Fusion ظریف است. کانسترهای ICP می‌توانند از طریق امضاهای آستانه‌ای با زنجیره‌های خارجی تعامل کنند، اما مدل امنیتی همچنان به بهداشت عادی API نیاز دارد: ورودی‌های محدود، ارتقاهای کنترل‌شده، آرتیفکت‌های قابل بازتولید و حالت‌های خطای قابل مشاهده. رمزنگاری این مسئولیت‌های مهندسی را حذف نمی‌کند؛ آن‌ها را به بخشی از مرز اعتماد میان‌زنجیره‌ای تبدیل می‌کند.

یک ملاحظه مهم این است که یادداشت انتشار v0.5.2 از سوءاستفاده یا حادثه‌ای شناخته‌شده نام نمی‌برد. بنابراین این تغییرات باید به‌عنوان سخت‌سازی دفاعی خوانده شوند، نه مدرکی برای افشای یک آسیب‌پذیری. همچنین صفحه رسمی مستندات زمان آخرین به‌روزرسانی محتوای فعلی را اعلام نمی‌کند؛ بنابراین نمونه‌های آن باید پیش از استفاده در محیط تولید با رابط مستقر تطبیق داده شوند.

برچسب‌هاChain FusionInternet ComputerChain Fusion SignerThreshold Cryptography
منابع مستند۲ مرجع
  1. [۰۱]Release v0.5.2 — dfinity/chain-fusion-signergithub.com ↗
  2. [۰۲]Chain Fusion Signer — ICP Developer Docsdocs.internetcomputer.org ↗
خواندنی بعدی

خبرخوان را در ایمیل بگیرید

هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.

خوراک RSS در دسترس · بدون هرزنامه