رمزنگاری خوب، داده را از غریبه پنهان می‌کند؛ طراحی بازیابی خوب، آن را از صاحبش پنهان نمی‌کند! امشب یک کلید بازیابی اضافه می‌کنیم و دربارهٔ بوت خودکار، TPM و شبکهٔ مورد اعتماد تصمیم می‌گیریم.

این جلسه بخشی از دورهٔ لینوکس ۳۰۳ در ۴۰ شب است.

محیط تمرین: Ubuntu 24.04؛ تصویر LUKS شب هشتم؛ VM آزمایشگاهی با کنسول؛ volume هنگام backup بسته باشد.

جایگاه در دوره: هدف‌های 331.3 آزمون 303-300.

keyslot راه ورود است، نسخهٔ پشتیبان داده نیست#

به vault.img دوباره loop device وصل کن و نام تازهٔ آن را از losetup --find --show بگیر؛ شمارهٔ loop قبلی ممکن است دیگر معتبر نباشد. volume را بسته نگه دار. در پوشهٔ ~/lpic303/storage:

loopdev=$(sudo losetup --find --show "$PWD/vault.img")
sudo cryptsetup luksAddKey "$loopdev"
sudo cryptsetup luksDump "$loopdev"
sudo cryptsetup luksHeaderBackup "$loopdev" --header-backup-file vault.header
sudo chmod 600 vault.header
sudo cryptsetup open --test-passphrase "$loopdev"

در luksAddKey ابتدا گذرواژهٔ فعلی و سپس گذرواژهٔ بازیابی متفاوت بده. با --test-passphrase هر دو را جدا امتحان کن؛ خروج صفر معیار پذیرش است. header backup بسیار حساس است: می‌تواند keyslotهای قدیمی را حفظ کند. ابطال یک گذرواژه روی دیسک، نسخه‌های header قدیمی را خودکار باطل نمی‌کند.

برای تمرین بازیابی، تصویر را در حالت بسته به فایل دیگری کپی و فقط روی آن Clone آزمایش کن. luksHeaderRestore روی مقصد اصلی می‌تواند دسترسی را خراب کند؛ در این درس روی volume اصلی اجرا نمی‌شود. backup header بدون ciphertext، backup فایل‌ها نیست.

وقتی سیستم خودش باز می‌کند#

/etc/crypttab نگاشت volume رمز‌شده را تعریف می‌کند؛ /etc/fstab مرحلهٔ mount فایل‌سیستم بازشده را مشخص می‌کند. نمونهٔ زیر قالب یک دیسک آزمایشگاهی پایدار است، نه خط آماده برای loop گذرای این درس:

labvault UUID=<LUKS-UUID> none luks

UUID را از cryptsetup luksUUID می‌گیری. این UUID با UUID فایل‌سیستم داخل mapper یکی نیست. مقدار none می‌تواند درخواست گذرواژه در بوت را ایجاد کند؛ آزمایش واقعی boot فقط روی VM Clone با کنسول انجام شود. cryptmount ابزار دیگری برای مدیریت نگاشت‌هاست؛ plain dm-crypt بدون header LUKS مدیریت و تشخیص پارامترها را بر عهدهٔ خودت می‌گذارد.

eCryptfs و بازکردن وابسته به محیط#

eCryptfs در سطح فایل‌سیستم و با mount لایه‌ای کار می‌کند؛ ابزارهای ecryptfs-* و pam_ecryptfs می‌توانند در بازکردن home هنگام ورود نقش داشته باشند. این همان dm-crypt نیست. قابلیت پشتیبانی توزیع و بازیابی کلید باید پیش از انتخاب بررسی شود؛ مثال قدیمی جزوه را به سیاست پیش‌فرض دسکتاپ امروزی تبدیل نمی‌کنیم.

Clevis چارچوب اتصال بازکردن کلید به یک سیاست است. Tang در NBDE، یعنی رمزگشایی وابسته به شبکه، به حضور در شبکهٔ موردنظر کمک می‌کند؛ TPM2 سخت‌افزار نگه‌داری راز و سنجش وضعیت بوت است. هیچ‌کدام به‌تنهایی مجوز انسانی برای خواندن تمام داده‌ها صادر نمی‌کنند. یک slot بازیابی مستقل نگه دار؛ قطع شبکه یا تغییر وضعیت بوت نباید تنها راه بازکردن را نابود کند.

مأموریت امشب#

سناریوی «Tang قطع است» و «کارمند جدا شده ولی header backup قدیمی دارد» را بنویس. برای هرکدام دارایی و راه بازگشت را مشخص کن. پایان تمرین: loop را detach کن و backup را در محل حفاظت‌شده نگه دار، نه مخزن وبلاگ.

منابع: crypttab در systemd ، Clevis و eCryptfs در کرنل .