‏فلش مموری‌ای که نصف خودشو پنهان می‌کنه

انگیزهٔ این پروژه از یه واقعیت ناخوشایند شروع می‌شه: تو خیلی جاها ممکنه کسی رو مجبور کنن رسانه‌اش رو رمزگشایی کنه، یا بدتر، صرفِ داشتن یه حجم رمزشده به معنی مجرم بودن گرفته بشه. نویسنده می‌گه حجم مخفی VeraCrypt برای حالت اول خوبه ولی برای حالت دوم کاری نمی‌کنه؛ برای همین Phantomdrive رو ساخته.

ایدهٔ اصلی ساده و هوشمندانه‌ست: درایو موقع اتصال فقط به‌شکل یه فلش ۸ گیگابایتی معمولی ظاهر می‌شه و سیستم‌عامل هیچ راهی برای دیدن بقیهٔ دیسک نداره. اگه کاربر یه فایل متنی ساده روی همون بخش رو ویرایش کنه و رمزش رو با پیشوند مشخصی بنویسه، دستگاه خودشو جدا می‌کنه و بخش دوم و پنهان رو سوار می‌کنه که رمزنگاری و رمزگشایی AES-256 روش در جا انجام می‌شه.

از نظر سخت‌افزار، همه‌چیز — فریم‌ور، سخت‌افزار و مهندسی مکانیک — متن‌بازه و حتی ابزارهای طراحی هم متن‌باز بودن. قلب دستگاه یه تراشهٔ CH569 از همون شرکت سازندهٔ CH340 ـه که تقریباً روی هر آردوینوی تقلبی پیدا می‌شه؛ از USB3، ‏SD/eMMC و بلوک AES ـش استفاده شده. به‌خاطر بالا بودن غیرعادی قیمت حافظهٔ eMMC (به گفتهٔ نویسنده به‌خاطر تقاضای هوش مصنوعی) فعلاً کارت SD به کار رفته و بدنه با اپوکسی چسبونده شده، یعنی مهاجم برای باز کردنش باید دستگاه رو نابود کنه.

بخش رمزنگاری مقاله آموزنده‌ترین قسمتشه. نویسنده از بدترین حالت ممکن شروع می‌کنه: گرفتن رمز و پر کردن انتهاش با صفر تا به ۳۲ بایت برسه. مشکل اینه که با یه رمز ضعیف، این تو چند دقیقه شکسته می‌شه و بدتر اینکه مهاجم می‌تونه از جدول کلید از پیش محاسبه‌شده استفاده کنه. راه‌حل اول اضافه کردن salt ـه؛ چون هر دستگاه salt یکتای خودشو داره، مهاجم مجبوره برای هر دستگاه جدا کلید حساب کنه و ضمناً نمی‌شه کارت SD رو از یه دستگاه درآورد و تو یکی دیگه گذاشت.

قدم بعدی، ۱۰۰ هزار دور SHA-256 روی تابع اشتقاق کلیده. نویسنده صادقانه توضیح می‌ده چرا دقیقاً همین عدد: باز شدن دستگاه با این تنظیم حدود ۳ ثانیه طول می‌کشه و بیشتر از این کُند می‌شه. الگوریتم‌هایی مثل Argon2 هم چون حافظه‌محورن روی این سخت‌افزار جواب نمی‌دن. اگه کسی امنیت بیشتری بخواد، می‌تونه تعداد دورها رو زیاد کنه یا روی همین دستگاه یه لایهٔ رمزنگاری نرم‌افزاری دوم بذاره.

بحث حالت‌های AES هم مرور خوبیه. حالت ECB ساده‌لوحانه‌ست چون بلوک‌های یکسان متن اصلی، متن رمز یکسان تولید می‌کنن و مهاجم می‌تونه داده رو به شکل قابل پیش‌بینی دستکاری کنه. حالت CTR این مشکل رو حل می‌کنه: شمارنده رو رمز می‌کنی و خروجی رو با متن اصلی XOR می‌کنی. نویسنده شبه‌کدش رو این‌طور می‌آره:

uint64_t i = 0;
while(i < len(ciphertext)) {
    ctr = aes_encrypt(i);
    ciphertext[i] = plaintext[i] ^ ctr;
    i++;
}

اما CTR یه ریسک شناخته‌شده به اسم «استفادهٔ مجدد از شمارنده» داره؛ اگه کسی دو بار در فاصلهٔ زمانی از متن رمز نسخه برداره و یکی از دو حالت رو حدس بزنه، می‌تونه اون یکی رو بازیابی کنه. حالت AES-XTS که استاندارد رمزنگاری دیسکه با دو کلید و یه tweak جدا برای هر سکتور این مشکل رو حل می‌کنه، ولی کندتره: روی این دستگاه CTR حدود ۹ مگابایت بر ثانیه نوشتن و ۲۰ خوندن می‌ده، در حالی که XTS به ۶ و ۱۰ می‌رسه. نویسنده فعلاً CTR رو انتخاب کرده و دلیلش رو هم شفاف گفته.

نکتهٔ فنی جالب دیگه اینه که دستگاه اصلاً از فایل‌سیستم خبر نداره؛ فقط دستورهای خام خواندن و نوشتن USB رو به دستورهای کارت SD ترجمه می‌کنه. برای همین در حالت قفل، قبل از هر نوشتن، دنبال الگوی رمز تو دادهٔ خام می‌گرده و اگه پیداش کرد، رمز رو تو حافظه کپی و بلافاصله همون قسمت بافر رو صفر می‌کنه تا رمز هیچ‌وقت روی دیسک نوشته نشه. عوارضش هم گفته شده: اگه فایل‌های عادی‌ات اتفاقی همون رشته رو داشته باشن، ممکنه تطابق ناخواسته رخ بده. نویسنده در ضمن اعتراف می‌کنه که به ایشوهای گیت‌هاب پروژه‌اش سر نمی‌زده و وقتی موجی از ایشوهای تولیدشده با هوش مصنوعی باز شد، متوجه نشد — که به گفتهٔ خودش اشتباه بزرگی از طرفش بوده.

نکات کلیدی:

• Phantomdrive موقع اتصال فقط ۸ گیگابایت نشون می‌ده و بخش دوم برای سیستم‌عامل نامرئیه
• باز شدن بخش پنهان با نوشتن رمز داخل یه فایل متنی روی خود درایو انجام می‌شه
• تراشهٔ CH569 با بلوک AES سخت‌افزاری، حافظهٔ کارت SD و بدنهٔ چسبیده با اپوکسی
• تابع اشتقاق کلید: رمز + salt یکتای هر دستگاه + ۱۰۰ هزار دور SHA-256 (حدود ۳ ثانیه باز شدن)
• انتخاب AES-CTR به‌جای AES-XTS بر اساس سرعت: ۹ در برابر ۶ مگابایت بر ثانیه نوشتن
• دستگاه از فایل‌سیستم بی‌خبره و رمز رو از دادهٔ خام می‌خونه، بعد بافر رو صفر می‌کنه تا روی دیسک ننویسه
• کل پروژه شامل فریم‌ور، سخت‌افزار و طراحی مکانیکی متن‌بازه