کراکن، نقصی جدی را در امنیت کیف پول ترزور شناسایی کرد!

*کراکن، امنیت کیف پول ترزور را به طور کامل زیر سوال برد.

Kraken Security Labs (آزمایشگاه‌ امنیتی کراکن) ، راهی برای استخراج عبارت seed (عبارت بازیابی کیف پول ارز دیجیتالِ) هر دو والت کریپتوی سخت افزاری ترزور، یعنی Trezor One و Trezor Model T ابداع کرد. همین مسئله، امنیت کیف پول ترزور را تا حد زیادی زیر سوال برد. چنین حمله ای، تنها به یک ربع دسترسیِ فیزیکی به دستگاه کیف پول کریپتویِ هدف نیاز دارد.

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

روند کار به این صورت است:

-این حمله، برای آنکه یک عبارت بازیابی را بیرون بکشد، به اختلال ولتاژ متکی است. تحقیقات اولیه روی این موضوع به دانش لازم از نحوه انجام کار و چند صد دلار تجهیزات نیاز داشت. اما طبق بررسی های انجام شده تخمین میزنیم ما (یا مجرمان) بتوانیم یک دستگاه اختلال که استفاده از آن نیز راحت باشد را در حجم انبوه تولید کنیم که فقط با قیمتی حدود 75 دلار به فروش برسد.

-سپس عبارت بازیابی رمزنگاری شده را که با یک پین 1 تا 9 رقمی محافظت شده است را می شکنیم. البته بدیهی است که برای این منظور به حمله بروت فورس نیاز است تا امنیت کیف پول ترزور را در هم بشکنیم.

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

امنیت کیف پول ترزور

تا آن زمان میتوانید اقدامات زیر را برای افزایش امنیت کیف پول ترزور خود انجام دهید:

-اصل اول برای افزایش امنیت کیف پول ترزور، این است که اجازه ندهید کسی به کیف پول شما دسترسی فیزیکی داشته باشد.

-عبارت عبور BIP39 خود را با Trezor Client فعال نمایید. استفاده از این عبارتِ عبور در عمل کمی سخت است، اما از آنجایی که روی دستگاه ذخیره نمیشود، عاملی جهت جلوگیری از این حمله و افزایش امنیت کیف پول ترزور شما محسوب میشود.

این حمله برای تست امنیت کیف پول ترزور، از بسیاری جهات شبیه به تحقیقات قبلی ما بر روی کیف پول KeepKey است که چندان هم دور از انتظار نبود. زیرا KeepKey و همه دستگاه های این چنینی به یک خانواده از تراشه ها متکی هستند. در واقع، ترزور از همان ابتدایِ طراحیِ کیف پول هایش از چنین نقصی مطلع بوده است. چنین تراشه هایی جهت ذخیره سازی اطلاعات رمزی طراحی نشده اند و فروشندگانی همچون ترزور و KeepKey نباید زیاد به آنها اعتماد کنند.

خوشبختانه ما به منظور هماهنگ سازی این افشاگری و بررسی امنیت کیف پول ترزور با تیم ترزور همکاری داریم.

مدیر ارشد فناوری SatoshiLabs ، Pavol Rusnak خاطر نشان کرد: “این باعث خوشحالی ماست که Kraken Security Labs در راستای بهبود امنیت کل اکوسیستم بیت کوین، منابع خود را سرمایه گذاری می کند و چنین افشاگری مسئولانه و همکاری متقابلی را بسیار ارج می نهیم.”

کراکن، کل جزئیات این حمله را به صورت مسئولانه در تاریخ 30 اکتبر 2019 برای تیم ترزور فاش کرد.

جزئیات فنی جهت تست سطح امنیت کیف پول ترزور

استخراج رمز بازیابی از کیف پول ترزور و تست کردن امنیت کیف پول ترزور حوزه جدیدی نیست.

ترزور، اقدامات کاهشی زیادی را در برابر انواع حملات سخت افزاری قبلی صورت داده است که از جمله آنها میتوان به کاهش موفق حملات اختلالی که در سخنرانی Wallet.Fail در سی و پنجمین کنگره جهانی هکرها به نمایش گذاشته شد، اشاره کرد.

این حمله بر مبنای همین تحقیق صورت گرفت تا آن اقدامات کاهشی را دور بزند.

این حمله با استفاده از حمله تزریق خطا که منجر به فعال کردن مجدد بوت لودر (bootloader) یکپارچه پردازنده میشود، آغاز می گردد.

کارکرد این بوت لودر یکپارچه این است که محتویات فلش دستگاه را بخواند، اما در زمان اجرای این دستور سطح حفاظت تراشه را نیز تایید می کند. با حمله تزریق خطای دوم، این امکان وجود دارد که از این بررسی احتراز کرد.

سپس کل محتوای فلش دستگاه میتواند در هر بار 256 بایت استخراج گردد.

با تکرار این پروسه میتوان تمام محتویات فلش را بیرون کشید.

همچنین، از آنجایی که میان افزارِ ترزور از یک فضای ذخیره سازی رمزگذاری شده بهره میگیرد،

یک اسکریپت به منظور شکستن پین دستگاهِ دامپ شده ایجاده کرده ایم که امنیت کیف پول ترزور را کاملاً به خطر می اندازد.

این اسکریپت با حمله بروت فورس قادر بود هر پین 4 رقمی را در کمتر از 2 دقیقه بشکند.

این حمله ثابت کرد که خانواده STM32 میکروکنترلرهای Cortex-M3/Cortex-M4 به هیچ عنوان نباید برای ذخیره‌سازی داده‌های حساسی مانند عبارات بازیابی رمزنگاری شده مورد استفاده قرار گیرند، حتی اگر تمام آنها در قالب رمزگذاری شده ذخیره شده باشند.

میکروکنترلر های مبتنی بر فلش

STM32F205 و STM32F427 میکروکنترلرهای مبتنی بر فلش هستند که در کیف پول های Trezor One و Trezor T مورد استفاده قرار می گیرند.

بسیاری از مشتقات Trezor One، همچون Keepkey نیز از STM32F205 بهره می گیرند.

هر دو STM32F2 و STM32F4 میکروکنترلرهای ARM Cortex-M3 از خانواده STM32 ST Microelectronics می باشند. STM32F2 و STM32F4 تمامی ملزومات جانبی مورد نیاز، از جمله PLL و همچنین رابط هایی مانند USB را جهت پیاده سازی کیف پول سخت افزاری فراهم می کند.

همچنین شایان ذکر است که STM32F205 دو رابط برنامه نویسی مشترک ARM، یعنی JTAG و ARM SWD و همچنین یک بوت لودر یکپارچه را نیز ارائه می دهد. این بوت لودر قابلیت این را دارد که با استفاده از رابط هایی مانند UART، USB و CAN برای برنامه دادن به دستگاه استفاده شود.

 

محافظت از خوانده شدن Flash و SRAM در STM32

خانواده STM32 یک مکانیزم امنیتی که به Read Protection (حفاظت از خوانده شدن) یا RDP معروف است را اجرا می کنند. درست همانند آنچه برای امنیت کیف پول ترزور بکار رفته است.

از آنجایی که تنها حافظه غیرفرار در دستگاه های ARM Cortex-M فلش مموری است، مقدار RDP در صفحه ویژه ای از فلش مموری ذخیره می گردد.

در غیر این صورت، برای نوشتن از کد برنامه، قابل دسترسی نخواهد بود. مقدار RDP توسط بیت های پیکربندی میکروکنترلر که به Option Bytes معروفند، تعریف می گردد. به طور کلی سه Option Byte Value وجود دارد که مربوط به سه سطح RDP در دستگاه های STM32 می باشند.

با توجه به اینکه تنها حافظه غیرفرار در میکروکنترلرهای STM32 فلش است، این تنها حافظه غیرفرار برای عبارات بازیابی رمزنگاری و کلیدهای خصوصی محسوب میشود.

در نتیجه، بسیار مهم است که فلش از خوانده شدن محافظت شود. خوشبختانه، ترزور و همه مشتقات آن از ویژگی RDP به درستی استفاده می کنند و در اولین راه‌اندازی خود با RDP ارسال می‌شوند و/یا RDP را روی RDP Level 2 تنظیم می‌کنند (به جدول 1 مراجعه کنید).

نتیجتاً، همیشه در عمل، یک میان ‌افزار غیرتوسعه‌ای روی دستگاه‌های کاربر در حالتRDP2 (RDP Level 2) قرار دارد، که مانعی برای دسترسی مهاجم به SRAM یا Flash محسوب میشود.

با این وجود، با توجه به نتایج تحقیقات Wallet.Fail و Chip.Fail، می توان با ایجاد اختلال ولتاژ در زمان راه اندازی، RDP2 را به RDP1 تنزل رتبه داد. زمانی که یک دستگاه در RDP1 قرار گرفت، میتوان SRAM آن را از طریق پروتکل عیب یابیARM SWD خواند.

به دلیل منطق پیچیده Power-On-Reset (POR) STM32، یک ادعای عادیِ ریست، یعنی سافت ریسِتی که در آن خط NRST برای مدت کوتاهی پایین نگه داشته می شود، منجر به POR کامل و اجرای مجدد BootROM نمی شود. این به نوعی تأیید بر این واقعیت است که تغییر در پیکربندی امنیتی، یعنی تغییر Option Bytes برای تغییر سطح RDP، عموماً نیاز به چرخه برق تراشه دارد.

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

در واقع، این بدان معنی است که یک مهاجم به صورت مکرر میتواند عملکرد دستگاه را مختل کند و زمانی که هنوز در حال اجرا BootRom است و یا زمانی که خیلی زودتر از موعد وارد کد اپلیکیشن شده است، بدون اینکه کد اپلیکیشن بارگذاری شده باشد، میتواند موفقیت آمیز بودن اختلال بوجود آمده را بررسی کند.

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

زمانی که که یک مهاجم دستگاهی را با موفقیت مختل می کند، به سادگی دستگاه را سافت ریست می کند.

در این حالت سیستم به فعالیت خود در RDP1 ادامه می دهد و از آن طرف به مهاجم این امکان را می دهد تا هر زمانی که خواست محتویات حافظه SRAM را بخواند.

این مسئله دردسرساز است، زیرا بسیاری از کتابخانه‌هایی که کریپتوگرافی لازم جهت امضای تراکنش‌های ارزهای دیجیتال را اجرایی می‌کنند، برای محاسبات خود به بارگذاری اطلاعاتِ حساس در SRAM تکیه دارند.

همچنین، ممکن است عبارت بازیابی حین استخراج کیف پول در SRAM و PIN کاربر نیز برای تأیید در برابر ورودی کاربر بارگیری شوند.

اگر میان ‌افزار زیربنایی تأیید شود یا اگر یک جمع‌بندی و تطبیق در راستای بررسی یکپارچگی میان ‌افزار محاسبه گردد، این احتمال وجود دارد که تمام این داده‌ها یا بخش هایی از آن نیز در معرض حملات O’Flynn Circuit Cellar قرار گیرند.

فرایند راه اندازی STM32 و پارامترهای اختلال

عمده رفتار یک میکروکنترلر با مقادیری که در هنگام روشن شدن می خواند، تعریف می گردد. اینها شامل پین‌های استریپی (strapped pins) که در زمان راه‌اندازی خوانده می‌شوند (پین‌های BOOT در مستندات STM32) و همینطور بیت‌های پیکربندی امنیتی (Option Bytes در مستندات STM32) می باشند.

لازم به ذکر است که بسیاری از جزئیاتی که در ادامه آمده است از طریق مهندسی معکوس تجربیِ رفتار بوت STM32F2 مشخص شده اند. بیشتر میکروکنترلرهای Cortex-M حاوی ROM هایی هستند که اصطلاحاً BootROM نامیده میشوند و در هنگام راه اندازی اجرا می شوند.

BootROM ها، نخستین قطعات نرم افزاری هستند که توسط یک تراشه اجرا می شوند و بارگذاری پارامترهای مهمی همچون پیکربندی امنیتی تراشه به عهده آنهاست.

پس از آن، برنامه کاربر یا کد اپلیکیشن اجرا می شود. در مورد یک کیف پول سخت افزاری، این میان افزارِ واقعی شرکت تولید کننده محسوب میشود. حتماً به این موضوع توجه داشته باشید، از آنجایی که حمله اختلالی مورد نظر ما کد BootRom را هدف قرار میدهد، نمیتوان آن را به طور کامل با هیچ اقدام متقابلی که در میان افزار شرکت سازنده اجرا شده است، کاهش داد.

کوچکترین آسیب پذیری در میان افزار، منجر به آسیب پذیری کل سخت افزار میشود که قابل اصلاح نیست و سخت افزار اصلی باید ویرایش شده و با یک سخت افزار جدید جایگزین شود. تنها در این صورت است که امنیت کیف پول ترزور افزایش خواهد یافت.

به احتمال زیاد، به دلیل پیچیدگی نسبی STM32F2، راه‌اندازی STM32 به درازا بکشد، تقریباً 1.2 تا 1.8 میلی‌ثانیه پس از چرخه برق منبع تغذیه تراشه.

مدت زمان راه‌اندازی را به دو روش میتوان به صورت مطمئن اندازه‌گیری کرد: یا با روش اندازه‌گیری مصرف برق دستگاه و اندازه‌گیری مدت زمانی که برای افزایش اولیه مصرف برق طول می‌کشد، به عنوان مثال با LSCM، یا با مشاهده رفتار ریست کردنِ (NRST/JTAG RST) خط میکروکنترلر. در 100 تا 200 میکروثانیه اول، BootROM تراشه اجرا می شود.

فعالسازی مجدد JTAG، SWD و بوت لودر BootROM  یکپارچه

حین راه اندازی STM32، BootROM یکپارچه قبل از آن که کد اپلیکیشن (یعنی میان افزار کیف پول) اجرا گردد، اجرا می شود. BootROM چندین بررسی را انجام میدهد تا به نوبه خود وضعیت امنیتی دستگاه را پیکربندی می کند.

این بررسی ها شامل فعال و یا غیرفعال کردن رابط های اشکال زدایی JTAG و SWD و همچنین بوت لودر BootROM یکپارچه می باشد. همانطور که گفتیم،

خانواده STM32 مبتنی بر فلش است، به همین دلیل تنها حافظه غیرفرار (NVM) در دسترس بر روی این دستگاه ها، فلش [Obermaier] است. از آنجایی که فلش تنها NVM موجود در STM32 می باشد، پیکربندی امنیتی باید در فلش نیز ذخیره گردد.

برای حفظ امنیت و پیکربندی دستگاه، یک بخش اختصاصی خاص در فلش وجود دارد که به نام Option Bytes (OB) شناخته میشود. OB حاوی Read-Protection Level (RDP Level) یا همان “سطح حفاظت از خواندن” است که در واقع به نوعی پیکربندی امنیتی دستگاه محسوب میشود و برای امنیت کلی دستگاه از هر چیز دیگر مهم تر است.

سطوح RDP شامل سطح 2 (Level 2) که در آن تمام رابط های اشکال زدایی و بوت لودرها غیرفعال میباشند، سطح 1 (Level 1) که در آن بخشی از عملکرد بوت لودر و قابلیت های اشکال زدایی به صورت محدود فعال است و نهایتاً سطح 0 (Level 0) که امکان دسترسی کامل را فراهم می کند، می باشند.

ترزور و مشتقات آن به صورت پیش فرض با RDP Level 2، قوی‌ترین سطح امنیتی ارائه شده توسط STM32 پیکربندی شده‌اند تا سطح امنیت کیف پول ترزور برای کاربر بسیار بالا باشد.

در زمان اجرای BootROM، مقدار RDP بررسی می گردد. اگر مقدار آن در زمان بررسی RDP، RDP 2 نبود، آن وقت BootROM بوت استراپینگ دو پین اختصاصی I/O را در برابر یک الگوی بوت (راه اندازی) از پیش تعریف شده، یعنی سطوح منطقی پین های BOOT0 و BOOT1 بررسی می‌ نماید.

اگر الگوی راه اندازی رعایت نشود، اجرای منظم ادامه پیدا می کند و کد اپلیکیشن از فلش اجرا می گردد. با این وجود، اگر الگو رعایت شود، یعنی در مورد STM32F2، اگر BOOT0 بالا و BOOT1 پایین باشد، بوت لودر سریال BootROM یکپارچه و بوت لودرهای DFU فعال می گردند.

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

بوت لودر STM32 BootROM

بوت لودر STM32 BootROM از دستوراتی متفاوت، از جمله دستوراتی که توانایی خواندن و نوشتن فلش را دارند، پشتیبانی می کند.

دستور “Read Memory” قابلیت آن را دارد که برای خواندنِ تا 256 بایت از محتویات فلش دستگاه استفاده شود. آنالیز BootROM مشخص کرد که هر بار که این دستور فراخوانده شود، سطح RDP را بررسی می کند و فقط زمانی که سطح RDP روی RDP Level 0 تنظیم شود، اجازه خواندن محتوای فلش را میدهد.

دور زدن بررسی RDP برای دستور Read Memory

STM32 هایی که در والت های کریپتویی چون Trezor One، جهت حفظ امنیت کیف پول ترزور، استفاده شده اند، در زمان تولید روی RDP Level 2 تنظیم می شوند.

همین امر موجب غیرفعال کردن تمامی ویژگی های اشکال زدایی و بوت لودر BootROM یکپارچه میشود. طبق تحقیقات Wallet.Fail، با اختلال ولتاژ این امکان وجود دارد که مقدار RDP ای که توسط Option Bytes خوانده میشود، تحریف شود.

تغییر تنظیمات امنیتی

در واقع، این مسئله به مهاجم اجازه میدهد تا پیکربندی امنیتی دستگاه مورد نظر را از RDP Level 2 به RDP Level 1 تنزل دهد. کاهش از RDP Level 1 به RDP Level 0، به دلیل فاصله بین RDP Level 0 و RDP Level 2 عملاً نشدنی است.

با ایجاد یک اختلال ولتاژ در حین اجرای BootROM، امکان فعال کردن مجدد رابط های اشکال زدایی JTAG و SWD وجود دارد. طبق نتایج بدست آمده از تحقیقات، مشخص شده است که بوت لودر BootROM یکپارچه نیز به شیوه ای مشابه میتواند دوباره فعال گردد.

به عنوان مثال، در STM32F205، با خطای تقریبی 170 میکروثانیه در اجرای BootROM، می‌توان JTAG و SWD را مجدداً فعال کرد.

ارتباط با بوت لودر

در واقع سیستم، رابط های JTAG و SWD را با عملکردی مشابه (یعنی همان محدودیت ها از نظر دسترسی) مانند RDP Level 1 فعال می کند.

همچنین مشخص شده که یک اختلال ولتاژِ تقریبی 180 میکروثانیه ای در اجرای BootROM، بوت لودر BootROM یکپارچه را نیز با همان عملکرد Bootloader در RDP Level 1 دوباره فعال می کند.

به محض برقراری ارتباط با بوت لودر BootROM یکپارچه، یعنی تکمیل فرآیند همگام سازی، این امکان وجود دارد که دستورات موجود در بوت لودر BootROM در RDP Level 1، برای مثال GET ID، صادر شود.

با این حال، دستوراتی که در RDP Level 1 موجود نیستند، منجر به برگشت یک NACK (عدم تصدیق) در STM32 و از کار افتادن آن میشوند.

با این وجود، مشخص شده که برای دستورات خاصی، یعنی خواندن حافظه، کنترل کننده فرمان بوت‌لودرِ BootROM سطح RDP دستگاه را برای هر فرمان صادر شده به آن بررسی می کند تا ببیند RDP Level 0 هست یا نه.

اختلال ولتاژی که با بررسی RDP Level کنترل کننده فرمان در حین پردازش دستوراتی که برای سطوح RDP، غیر از سطح RDP 0، غیرفعال هستند، همزمانی داشته باشد، منجر به دور زدن فرایند بررسیRDP Level شده و در نتیجه به موفقیت آمیز شدن فرمان می انجامد.

ایجاد اختلال

این به این معنی است که این امکان وجود دارد که در دستوراتی که باید بر اساس پیکربندی RDP دستگاه (یعنی دور زدن کنترل‌کننده فرمانی که باید سیگنال عدم تایید را صادر کند) با شکست مواجه شوند، اختلال ایجاد کرد.

در نتیجه، اجرای دستوراتی که در RDP Level 1 یا RDP Level 2 در دسترس نیستند، نیز ممکن است.

اگر دستور خواندن داده شود، خواندن خودسرانه فلش مموری از میکروکنترلر ممکن است.

از آنجایی که عبارت های بازیابیِ رمزنگاریِ بسیاری از کیف پول هایی که مبتنی بر STM32 هستند، در فلش STM32 ذخیره می شوند، عبارت بازیابی این دستگاه ها نیز می تواند به خطر بیفتد. همین امر است که امنیت کیف پول ترزور را نیز تهدید می کند.

تنظیم سخت افزار اختلال ولتاژ برای دامپ فلش

از یک برد توسعه Digilent Arty A7 FPGA، هم برای اختلال و تولید پالس و هم به عنوان ابزار دقیق STM32 و ابزاری جهت زمان‌بندی دقیق اختلال استفاده شد.

یک برد برک آوتِ بر پایه FTDI FT232H، به نام Adafruit FT232H، نیز برای ارتباط پیاپی UART با کنترل کننده فرمان بوت لودر BootROM استفاده شد.

همچنین، یک مالتی پلکسر Maxim MAX4619 نیز برای مخابره ترکیبی بین یک ولتاژ عملیاتی نامی برای ولتاژ هسته پردازنده STM32 و ولتاژ اختلال، یعنی GND یا 0v استفاده شد.

یک برد BreakingBitcoin نیز به جهت تسهیلِ تعامل استفاده شد که در واقع یک برد برک اوت ترزورِ سازگار با پین است.

چنین حمله ای را می شد در محل روی یک کیف پول سخت افزاری نیز اجرا کرد.

با این وجود، برداشتن میکروکنترلر و قرار دادن آن در یک سوکت به مراتب ساده‌تر از لحیم کردن تمام اتصالات (عمدتا Boot0 و Boot1) برای حمله درجا بود.

بروت فورس کردنِ پینِ یک دامپ فلش

حافظه محرمانه کیف پول ترزور با کلیدی که از پین و salt گرفته شده است، رمزگذاری می گردد.

به طور کلی salt، شامل یک salt سخت افزاری است که در بایت های OTP ذخیره شده است و یک salt رندوم و تصادفی از فلش که در فرآیند آماده سازی دستگاه تولید می گردد.

طول salt سخت افزاری 44 بایت است و با یکبار خواندن option bytes قابل خواندن است.

Trezor، برای امنیت کیف پول ترزور، فضای ذخیره‌سازی خود را در «ورودی‌ها» سازمان‌دهی می‌کند، که شناسایی آنها با استفاده از مقدار برنامه و مقدار کلید آنها قابل انجام است.

ورودی، عموماً شامل salt، کلید رمزگذاری داده های رمزگذاری شده (Encrypted Data Encryption Key) یا به اختصار همان (EDEK)، کلید احراز هویت ذخیره سازی رمزگذاری شده (Encrypted Storage Authentication Key) یا همان (ESAK) و کد تایید پین (PVC) است.

آن را میتوان زیر مقدار برنامه 0 (app-value 0) و کلید مقدار 2 یافت. از آنجایی که این ورودی، با هگزهای “02 00 3C 00” آغاز میشود، پیدا کردن آن محتمل است. طول یک ورودی کامل شامل 64 بایت است.

به این ترتیب اگر با خواندن salt سخت افزاری ترکیب شود، جهت 2 خواندن موفق کافی میباشد (چون در هر بار خواندن 256 بایت بیرون کشیده میشود).

به محض اینکه salt، EDEK، ESAK و PVC بازیابی شدند، باید از بایت های OTP یک salt سخت افزاری مازاد بازیابی شود.

این کار توسط فعال کردن مجدد رابط SWD یا بوت لودر BootRom و صدور دستورات خواندن حافظه مربوطه قابل انجام است.

با استفاده از کتابخانه “pycryptodome” پایتون، عملکردِ تقریبی 85 هش در ثانیه در یک CPU تک هسته ای به دست آمد. با استفاده از یک GPU، امکان بهینه سازی چشمگیر این مسئله وجود دارد. حتی با این سرعت آهسته نیز یک پین 4 رقمی در کمتر از 2 دقیقه میتواند مورد حمله بروت فورس قرار گیرد.

مشتق کلید

Salt که متشکل از salt سخت افزاری است که به salt ورودی الحاق شده است، در ترکیب با پین (پیشوند با یک 1 و تبدیل شده به یک عدد صحیح اندیان کوچک 32 بایتی) بکار برده میشود تا یک کلید را با استفاده از PBKDF2-HMAC با SHA256 بدست آورد. طول یک کلید مشتق شده، 362 بیت میباشد. 256

بیت اولِ نتیجه، به عنوان KEK استفاده می شود، در حالی که 96 بیت آخر به عنوان بردار اولیه رمزگذاری کلید (Key Encryption Initialization Vector) یا همان (KEIV) استفاده می شود.

تایید کلید

کلید رمزگذاری داده ها (DEK) از EDEK تولید می شود. برای این منظور EDEK با استفاده از KEK و KEIV رمزگشایی می شود. الگوریتم رمزگذاری مورد استفاده برای آن ChaCha20 با کد احراز هویت Poly1305 میباشد.

اگر 64 بیت اول PVC با 64 بیت اول TAG همسان باشند، در آن صورت پین صحیح بوده و DEK با موفقیت بازیابی شده است.