حملات قالب‌پذیری تراکنش‌ها(transaction malleability) در بلاکچین

خیلی‌ها در حوزه کریپتو راجع به حملات قالب‌پذیری تراکنش‌ها (transaction malleability) شنیده‌اند و می‌دانند اتفاق بدی است. اما قالب‌پذیری تراکنش‌ها چیست و چرا بد است؟

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

خب حالا کاربرها چگونه می‌توانند فورا در میان هزاران تراکنشی که وجود دارد تراکنش مربوط به خودشان را تشخیص دهند و آنها را از هم تمییز دهند؟ چگونه دسته‌ای از کاربران که در سرتاسر جهان منتشر هستند و اتصالی به هم ندارند می‌توانند بدون اینکه به نوعی از سیستم‌های ثبت کُند جهانی اتکا کنند، به سرعت و به نحوی بی نظیر و منحصر به فرد تراکنش‌ها را به یک شکل واحد شناسایی کنند. پاسخ ساده است؛ از هش رمزنگاری شده آن تراکنش بعنوان شناسه آن استفاده می‌کنند.

هش رمزنگاری شده به هر کسی این اجازه را می‌دهد که بتواند فقط با استفاده از داده‌ها اثر انگشت دیجیتالی (fingerprint) آن داده‌ها را بدست آورد. این اثر انگشت دیجیتالی (fingerprint) هر بار که محاسبه شود منحصر به فرد و یکتاست. حتی اگر یک بیت از داده‌ها را تغییر دهید مقدار هش اثر انگشت (fingerprint) تغییر می‌کند. در بیتکوین به هش تراکنش‌ها، TXID گفته می‌شود و بعنوان شناسه منحصر به فرد جهانی تراکنش‌ها عمل می‌کند.

بسیار عالی، خب حالا قالب‌پذیری (malleability) چیست؟

قالب‌پذیری تراکنش‌ها (malleability)

قالب‌پذیری (malleability) یعنی امکان تغییر دادن شناسه یک تراکنش (یعنی تغییر دادن TXID) بدون اینکه آن تراکنش اعتبارش را از دست بدهد. بسته به نوع رمزارز، روش‌های زیادی برای انجام این کار وجود دارد. یکی از روش‌های شایع در میان تمامی رمزارزها استفاده از قالب‌پذیری امضا یا همان signature malleability است که در این مقاله روی آن تمرکز می‌کنیم.

با توجه به نحوه کار امضاهای ECDSA به لحاظ ریاضی، این امکان وجود دارد که بتوان امضاها را بدون اینکه تراکنش نامعتبر شود تغییر داد. اگرچه این امر امکان و اجازه جعل کردن آن امضاها را نمی‌دهد ولی به مهاجمین این امکان را می‌دهد که TXID تراکنشی که حاوی آن امضا است را تغییر دهند و این کار می‌تواند پیامدهای جدی و نامطلوبی داشته باشد.

حمله قالب‌پذیری (malleability)

فرض کنید رضا از طریق تراکنشی با شناسه X مقداری بیتکوین به حسن انتقال می‌دهد. فرض کنید که قبل از اینکه این تراکنش ماین و استخراج شود، شناسه این تراکنش که X است به نوعی قالب‌دهی شود که تبدیل به شناسه 'X شود. حسن این پرداخت را دریافت کرده است اما رضا این موضوع را نمی‌داند. حالا حسن که وانمود می‌کند که چیزی دریافت نکرده از رضا می‌خواهد که دوباره تراکنش را انجام دهد. حسن انقدر این کار را ادامه می‌دهد تا بالاخره رضا متوجه شود که چه اتفاقی در حال رخ دادن است اما شاید دیگر خیلی دیر شده باشد. این نوع حمله به صورت عملی هم در صرافی‌ها به نحو زیر اتفاق افتاده است بعنوان مثال خسارات متعددی که صرافی مشهور و ورشکسته Mt Gox متحمل شده, آن چنان که کارشناسان فنی و مدیرعامل آن Mark Karpeles اظهار داشته‌اند به دلیل مسأله قالب‌پذیری تراکنش‌ها بوده است. در هکی که برای این صرافی اتفاق افتاده تقریبا 850000 بیتکوین به سرقت رفت و این صرافی در سال 2014 ورشکسته شد.

با این وجود تحقیقات انجام شده نشان داده که این ورشکستگی تنها به دلیل مسأله قالب‌پذیری تراکنش‌ها نبوده و سهم این مسأله در از دست رفتن بیتکوین‌ها بیشتر از 400 واحد تشخیص داده نشده است و ما بقی به دستکاری داده‌ها توسط تیم این صرافی نسبت داده شده است.

در این سناریو حمله، مهاجم به ترتیب کارهای زیر را انجام می‌دهد:

1- نودهایی مخرب و با هویت‌های جعلی (Sybil nodes) راه اندازی می‌کند. (نودهای قرمز رنگ)

2- نود صرافی(نود زرد رنگ) را با نودهای مخرب و با هویت جعلی خودش محاصره می‌کند.

3- از صرافی برداشتی انجام می‌دهد.

4- به محض اینکه تراکنش برداشت X از سوی صرافی صادر می‌شود، نودهای مخرب اقدام به قالب‌دهی شناسه یا TXID آن تراکنش به 'X می‌کنند.

5- حالا این تراکنش قالب‌دهی شده را به اطلاع بقیه شبکه می‌رسانند.

وقتی تراکنش 'X در بلاک بعدی ماین و استخراج شود ، مهاجم وجه مربوطه در تراکنش اولیه که شناسه اش به 'X تغییر داده شده را دریافت کرده ولی بکند(backend) صرافی تاییدیه این وصولی را از شبکه دریافت نکرده چرا که برای این منظور در شبکه به دنبال شناسه تراکنش X می‌گردد که دیگر وجود ندارد. مهاجم با علم به این موضوع اقدامات زیر را انجام می‌دهد:

6- از صرافی می‌خواهد که تراکنش را مجددا تکرار کند چرا که «انجام نشده و به دستش نرسیده»

7- و همین کار را بارها و بارها تکرار می‌کند.

بسته به میزان بزرگی صرافی، مهاجم ممکن است از «استراتژی انگلی» استفاده کند که به موجب آن به صورت خرد خرد و به تدریج و نه یکباره اقدام به خالی کردن جیب صرافی‌ها می‌کند. با این شیوه می‌تواند از جلب توجه کردن در امان بماند و در نتیجه بتواند مدت طولانی‌تری به این روش کلاهبرداری کند. یا ممکن است از «استراتژی خون آشام» استفاده کند که به موجب آن تا پیش از این که مدیران سیستم صرافی بتوانند پاسخ و واکنشی نشان دهند، به صورت مکرر اقدام به برداشت مقادیر بالا از صرافی کند.

اینکه مهاجم از چه استراتژی‌ای استفاده کند فرقی نمی‌کند، اینجا مسأله‌ای امنیتی وجود دارد که طراحان باید برایش چاره‌ای بیاندیشند.

توجه داشته باشید که در مرحله 2 لازم نیست که مهاجم به طور کامل نود(node) صرافی را محاصره کند، تنها چند اتصال برای انجام این حمله کفایت می‌کند البته احتمال موفقیت پایین‌تر می‌آید. هرچه نود صرافی بیشتر محاصره شده باشد احتمال موفقیت حمله بیشتر خواهد شد.

بیتکوین به کمک Segwit این مسأله را حل کرده است که به موجب آن، امضای دیجیتالی از محاسبه TXID تفکیک و مجزا می‌شود و از یک هش قالب‌ناپذیر (non-malleable) به جای امضاها استفاده می‌کند.

این هش بعنوان اشاره‌گری برای امضایی که در ساختار داده‌ای دیگری ذخیره‌سازی شده است عمل می‌کند. برای صحت‌سنجی امضای تراکنش، فردی که می‌خواهد صحت‌سنجی کند از این هش برای جستجو و یافتن امضایی که در آن ساختار داده‌ای دیگر ذخیره‌سازی شده استفاده می‌کند و سپس بقیه مراحل صحت‌سنجی ECDSA را طبق معمول ادامه می‌دهد. این کار باعث می‌شود که امضاها بعنوان منبع و ریشه ایجاد مساله قالب‌پذیری (malleability) از تراکنش‌ها حذف شوند چرا که دیگر در خارج از تراکنش‌ها ذخیره‌سازی می‌شوند و هش اشاره‌گر به آن هم که در تراکنش جای آن را گرفته، قالب‌پذیر(malleable) نیست. اقدام جالب توجهی است اما این کار به معنی ایجاد یک وابستگی به ساختار داده‌ای دیگر است که حاوی امضای دیجیتالی تراکنش است. می‌توان گفت که این کار برای بیتکوین بده بستان کوچکی محسوب می‌شود ولی به هر صورت اقدام مهم و چشمگیری است.

در حالی که Segwit به خودی خود ایده بدی نبوده است، اما نحوه استقرار آن و سیاست‌های ناشی از آن باعث بروز شکافی در بدنه جامعه دست اندرکاران بیتکوین شد. این امر باعث جدا شدن این جامعه به دو دسته Bitcoin (BTC) و Bitcoin Cash (BCH) شد. اگر چه Segwit بعنوان یکی از دلایل اصلی این انشقاق و جدایی عنوان شده است اما دلایل اصلی این امر بیشتر به نحوه استقرار Segwit مربوط بوده تا به مسائل فنی مرتبط با آن. همچنین، سیاست «سافت فورک همیشه، هاردفورک هرگز » هم به معنی این بود که اندازه 1 مگابایتی برای بلاک‌ها غیرقابل چانه‌زنی و موضوعی تثبیت شده است و این برای خیلی‌ها قابل قبول نبود.

اتریوم چطور؟

اتریوم هم در هارد فورک Homestead که در پیشنهاد بهبود اتریوم EIP-2 توضیح داده شده، اعلام کرد که از این پس کلیه امضاهایی از تراکنش‌ها که مقدار s-value در آنها بیشتر از secp256k1n/2 باشد را نامعتبر در نظر می‌گیرد و به این طریق مسأله قالب‌پذیری تراکنش‌ها را حل کرد.

دوستان لطفا اگه از این مطلب خوشتون اومد حتما برای حمایت پست رو لایک کنید و برای دوستانتون هم فوروارد کنید و صفحه من در توییتر و کانال تلگرام رو هم حتما فالو کنید و عضو بشید. ممنون

صفحه توییتر:

http://twitter.com/BitcoinBreads

کانال تلگرام:

https://t.me/BitcoinBreads