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

نسخهٔ ۰.۵.۲ Chain Fusion Signer ورودی‌های کلید را به یک رابط محدودشده تبدیل می‌کند

آخرین نسخهٔ Chain Fusion Signer دو مرز ورودی را مقاوم‌تر می‌کند و هم‌زمان مسیر عملیاتی استقرار و راستی‌آزمایی این سرویس را بهبود می‌دهد.

نسخهٔ ۰.۵.۲ Chain Fusion Signer ورودی‌های کلید را به یک رابط محدودشده تبدیل می‌کند
تصویر: تولید هوش مصنوعی

انتشار نسخهٔ ۰.۵.۲ از Chain Fusion Signer یک به‌روزرسانی کوچک اما مهم در حوزهٔ نگهداری امنیتی است: این نسخه با ورودی‌های تحت کنترل فراخواننده مانند منابعی رفتار می‌کند که باید پیش از رسیدن به APIهای امضای Internet Computer محدود شوند.

این نسخه، ingress بیش‌ازحد بزرگ را برای متدهای کلید عمومی با کارمزد ثابت رد می‌کند و طول مسیر مشتق‌سازی و نام کلیدی را که signer به API پایین‌دستی ارسال می‌کند محدود می‌سازد. یادداشت انتشار مقدار عددی این محدودیت‌ها را اعلام نمی‌کند؛ بنابراین نباید از این تغییر، حداکثر اندازهٔ مشخصی برای درخواست یا طول مشخصی برای مسیر نتیجه گرفت. اهمیت اصلی تغییر، معماری است: یک canister عمومی و مشترک برای امضا باید پیش از ارسال داده به APIهای کلید پروتکل، ورودی‌ها را محدود کند.

این موضوع از آن جهت مهم است که Chain Fusion Signer برای در دسترس قرار دادن قابلیت‌های threshold ECDSA و Schnorr در وب‌اپلیکیشن‌ها و ابزارهای خط فرمان طراحی شده است، بدون آن‌که هر توسعه‌دهنده مجبور باشد canister پشتیبان جداگانه‌ای مستقر کند. مستندات توسعه‌دهندگان ICP آن را یک canister عمومی و تحت کنترل حاکمیتی معرفی می‌کنند که فراخوانی‌هایش با cycles پرداخت می‌شود. در نتیجه، یک درخواست معیوب یا بی‌دلیل بزرگ به یک مرز سرویس مشترک فشار وارد می‌کند، نه فقط به یک برنامهٔ محلی.

این انتشار، سمت عملیاتی همین مرز را نیز تقویت می‌کند. تغییرات نگهداری شامل استقرار دقیق WASM انتشار در staging و حفظ پیکربندی staging هنگام ارتقا، افزودن manifest مربوط به test_proxy به ساخت وابستگی Docker برای موفق شدن ساخت قابل‌بازسازی، و توضیح روش راستی‌آزمایی آرگومان ارتقاست. اسکریپت‌ها همچنین طوری تغییر کرده‌اند که هنگام ساخت پیشنهاد، PIN مربوط به HSM را echo نکنند. این تغییرات، هویت artifact، حفظ پیکربندی و حفاظت از اسرار را در فرایند انتشار به هم متصل می‌کنند.

برای اپراتورها، پیام عملی این است که v0.5.2 را یک نقطهٔ کنترل برای کد و فرایند بدانند. بررسی کنید WASM مستقرشده با انتشار موردنظر مطابقت داشته باشد، آرگومان ارتقا را پیش از ارسال بازبینی کنید و مطمئن شوید پیکربندی staging حفظ شده است. برای یکپارچه‌سازها، نباید فرض کرد محدودیت‌های جدید نیاز به اعتبارسنجی در سطح برنامه را از بین می‌برند: یادداشت انتشار مقدار عددی محدودیت‌ها را فاش نمی‌کند و ادعای یک ممیزی کامل امنیتی هم ندارد. این ابهام دلیلی است برای آن‌که اعتبارسنجی اندازهٔ درخواست، مسیر مشتق‌سازی و نام کلید در کلاینت‌ها همچنان صریح باقی بماند و رفتار خطا پس از ارتقا آزمایش شود.

درس گسترده‌تر این است که قابلیت اطمینان Chain Fusion فقط به امضای رمزنگاری‌شده خلاصه نمی‌شود. وضعیت امنیتی signer به رابط‌های عادی پیرامون امضا نیز وابسته است: محدودیت‌های ingress، شناسه‌های ارسالی، artifactهای قابل‌بازسازی، معنای ارتقا و حفاظت از اعتبارنامه‌های اپراتور.

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

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

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

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