volume-name encrypted-device key-file options

1.فیلد اول شامل نام حجم حاصل با داده‌های رمزگشایی‌شده است؛ دستگاه بلاک آن در مسیر /dev/mapper/ راه‌اندازی می‌شود.

2.فیلد دوم شامل مسیری به دستگاه بلاک یا فایل زیرین است، یا مشخصه‌ای از یک دستگاه بلاک از طریق "UUID=" به همراه UUID مربوطه است.

3.فیلد سوم یک مسیر مطلق به فایلی حاوی کلید رمزنگاری را مشخص می‌کند. به صورت اختیاری، مسیر می‌تواند با ":" و یک مشخصه دستگاه به سبک /etc/fstab دنبال شود (مثلاً شروع‌شده با "LABEL=" یا موارد مشابه)؛ که در این صورت مسیر نسبت به ریشه سیستم‌فایل دستگاه مشخص‌شده در نظر گرفته می‌شود. اگر این فیلد وجود نداشته باشد یا برابر با "none" یا "-" باشد، یک فایل کلید هم‌نام با حجم مورد نظر برای بازگشایی (یعنی ستون اول خط)، با پسوند .key به صورت خودکار از دایرکتوری‌های /etc/cryptsetup-keys.d/ و /run/cryptsetup-keys.d/ (در صورت وجود) بارگذاری می‌شود. در غیر این صورت، گذرواژه باید در طول بوت سیستم به صورت دستی وارد شود. برای رمزنگاری swap، می‌توان از /dev/urandom به عنوان فایل کلید استفاده کرد که منجر به یک کلید تصادفی می‌شود.

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

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

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

2.کلید (رمزنگاری‌نشده) ممکن است از یک فایل روی دیسک، احتمالاً روی رسانه‌های جداشدنی خوانده شود. فیلد سوم هر خط مکان آن را مشخص می‌کند؛ برای جزئیات به بالا مراجعه کنید.

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

4.کلید ممکن است از طریق یک توکن امنیتی سخت‌افزاری یا کارت هوشمند سازگار با PKCS#11 دریافت شود. در این حالت، یک کلید ذخیره‌شده که در فرآیند بازگشایی استفاده می‌شود روی دیسک/رسانه جداشدنی ذخیره شده، از طریق AF_UNIX دریافت شده، یا در هدر متادیتای توکن JSON مربوط به LUKS2 ذخیره می‌شود. برای RSA، کلید ذخیره‌شده یک کلید رمزنگاری‌شده حجم است. کلید حجم رمزنگاری‌شده سپس توسط توکن PKCS#11 با کلید خصوصی RSA ذخیره‌شده روی آن رمزگشایی می‌شود و برای بازگشایی حجم رمزنگاری‌شده مورد استفاده قرار می‌گیرد. برای رمزنگاری منحنی بیضوی (EC)، کلید ذخیره‌شده همان کلید عمومی تولیدشده در فرآیند ثبت‌نام است. سپس از این کلید عمومی برای اشتقاق یک رمز مشترک با یک کلید خصوصی ذخیره‌شده در توکن PKCS#11 استفاده می‌شود. رمز مشترک اشتقاق‌یافته سپس برای بازگشایی حجم به کار می‌رود. برای استفاده از این سازوکار از گزینه pkcs11-uri= که در زیر توصیف شده است استفاده کنید.

5.به طور مشابه، کلید ممکن است از طریق یک توکن امنیتی سخت‌افزاری سازگار با FIDO2 (که باید افزونه "hmac-secret" را پیاده‌سازی کرده باشد) دریافت شود. در این حالت، کلیدی که به صورت تصادفی در حین ثبت‌نام تولید شده است، روی دیسک/رسانه جداشدنی ذخیره شده، از طریق AF_UNIX دریافت شده، یا در هدر متادیتای توکن JSON مربوط به LUKS2 ذخیره می‌شود. کلید تصادفی از طریق یک تابع درهم‌سازی کلیددار (HMAC) روی توکن FIDO2، با استفاده از یک کلید مخفی ذخیره‌شده روی توکن که هرگز از آن خارج نمی‌شود، هش می‌شود. مقدار هش حاصل سپس به عنوان کلید برای بازگشایی حجم رمزنگاری‌شده استفاده می‌شود. برای استفاده از این سازوکار از گزینه fido2-device= که در زیر توصیف شده است استفاده کنید.

6.به طور مشابه، کلید ممکن است از طریق یک تراشه امنیتی TPM2 دریافت شود. در این حالت، یک کلید که (در طول ثبت‌نام) به صورت تصادفی تولید شده است — رمزنگاری‌شده توسط یک کلید نامتقارن مشتق‌شده از کلید سید (seed) تراشه TPM2 — روی دیسک/رسانه جداشدنی ذخیره شده، از طریق AF_UNIX دریافت شده، یا در هدر متادیتای توکن JSON مربوط به LUKS2 ذخیره می‌شود. برای استفاده از این سازوکار از گزینه tpm2-device= که در زیر توصیف شده است استفاده کنید.

الگوریتم رمزنگاری مورد استفاده را مشخص می‌کند. برای مقادیر ممکن و مقدار پیش‌فرض این گزینه، cryptsetup(8) را ببینید. استفاده از یک الگوریتم رمزنگاری با مقادیر بردار اولیه (IV) غیرقابل پیش‌بینی، مانند "aes-cbc-essiv:sha256" توصیه می‌شود. کاماهای تعبیه‌شده در مشخصه الگوریتم باید با قرار دادن یک بک‌اسلش در پیش از آن‌ها اسکیپ شوند؛ مثال زیر را ببینید.

اضافه‌شده در نسخه 186.

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

اضافه‌شده در نسخه 207.

تابع درهم‌سازی مورد استفاده برای هش کردن گذرواژه را مشخص می‌کند. برای مقادیر ممکن و مقدار پیش‌فرض این گزینه، cryptsetup(8) را ببینید.

اضافه‌شده در نسخه 186.

از یک دستگاه یا فایل متادیتای جداگانه (جداشده) که هدر حاوی کلید(های) اصلی در آن ذخیره شده است استفاده می‌کند. این گزینه فقط برای دستگاه‌های LUKS و TrueCrypt/VeraCrypt کاربرد دارد. برای مقادیر ممکن و مقدار پیش‌فرض این گزینه، cryptsetup(8) را ببینید.

به صورت اختیاری، مسیر ممکن است با ":" و یک مشخصه دستگاه به سبک /etc/fstab دنبال شود (مثلاً شروع‌شده با "UUID=" یا موارد مشابه)؛ که در این صورت، مسیر نسبت به ریشه سیستم‌فایل دستگاه در نظر گرفته می‌شود. دستگاه فقط برای مدت‌زمان فعال‌سازی دستگاه LUKS به طور خودکار سوار (mount) می‌شود.

اضافه‌شده در نسخه 219.

تعداد بایت‌هایی که باید در ابتدای فایل کلید نادیده گرفته شوند را مشخص می‌کند. برای مقادیر ممکن و مقدار پیش‌فرض این گزینه، cryptsetup(8) را ببینید.

اضافه‌شده در نسخه 187.

حداکثر تعداد بایت‌هایی را که باید از فایل کلید خوانده شود مشخص می‌کند. برای مقادیر ممکن و مقدار پیش‌فرض این گزینه، cryptsetup(8) را ببینید. این گزینه در حالت رمزنگاری plain نادیده گرفته می‌شود، جایی که اندازه فایل کلید با اندازه کلید تعیین می‌شود. همچنین هنگامی که فایل کلید به عنوان فایل سالت (salt) برای یک توکن FIDO2 استفاده می‌شود نادیده گرفته می‌شود، زیرا اندازه سالت در آن حالت توسط مشخصات FIDO2 دقیقاً ۳۲ بایت تعریف شده است.

اضافه‌شده در نسخه 188.

در صورت فعال بودن، فایل کلید مشخص‌شده پس از فعال‌سازی حجم یا در صورت ناموفق بودن فعال‌سازی پاک می‌شود. این گزینه به‌ویژه زمانی مفید است که فایل کلید فقط به صورت گذرا قبل از فعال‌سازی دریافت می‌شود (مثلاً از طریق فایلی در /run/ که توسط سرویسی در حال اجرا قبل از فعال‌سازی ایجاد شده است)، و باید پس از استفاده حذف شود. به طور پیش‌فرض غیرفعال است.

توجه داشته باشید که این گزینه فقط برای یک فایل کلید که صراحتاً در فیلد سوم پیکربندی شده است اعمال می‌شود، و هیچ تأثیری بر فایل‌های کلیدی که به طور خودکار در /etc/cryptsetup-keys.d/ و /run/cryptsetup-keys.d/ کشف می‌شوند ندارد. موارد اخیر به عنوان منابع مشترک در نظر گرفته می‌شوند که متعلق به یک حجم منفرد نیستند و بنابراین هرگز پاک نمی‌شوند. برای پاک کردن یک فایل کلید کشف‌شده به صورت خودکار، مسیر آن را صراحتاً در فیلد سوم پیکربندی کنید.

اضافه‌شده در نسخه 246.

اسلات کلید را برای مقایسه عبارت عبور یا کلید در برابر آن مشخص می‌کند. اگر اسلات کلید با عبارت عبور یا کلید داده‌شده مطابقت نداشته باشد، اما اسلات دیگری مطابقت داشته باشد، با این وجود راه‌اندازی دستگاه ناموفق خواهد بود. این گزینه مستلزم luks است. برای مقادیر ممکن، cryptsetup(8) را ببینید. پیش‌فرض این است که همه اسلات‌های کلید به ترتیب متوالی امتحان شوند.

اضافه‌شده در نسخه 209.

مدت‌زمان انتظار (مهلت زمانی) را برای دستگاهی که فایل کلید روی آن قرار دارد یا دستگاهی که به عنوان فایل کلید استفاده می‌شود مشخص می‌کند، و در صورتی که قابل دسترسی نباشد به درخواست گذرواژه بازمی‌گردد. برای فایل‌های کلید روی دستگاه‌های خارجی، systemd-cryptsetup-generator(8) را ببینید.

اضافه‌شده در نسخه 243.

دسته‌کلید کرنل (keyring) و توضیحات کلید (نگاه کنید به keyrings(7)) را مشخص می‌کند که کلید حجم LUKS2 در حین فعال‌سازی دستگاه به آن پیوند می‌یابد. توضیحات دسته‌کلید کرنل و توضیحات کلید باید با "::" از هم جدا شوند.

بخش دسته‌کلید کرنل می‌تواند یک رشته توضیحات یا یک دسته‌کلید کرنل از پیش تعریف‌شده باشد که با "@" پیشوند شده است (مثلاً برای استفاده مستقیم از دسته‌کلید نشست "@s" یا دسته‌کلید کاربر "@u"). متن پیشوند نوع در توضیحات دسته‌کلید کرنل الزامی نیست. دسته‌کلید کرنل مشخص‌شده باید از قبل در زمان فعال‌سازی دستگاه وجود داشته باشد.

بخش کلید یک رشته توضیحات است که به صورت اختیاری با یک "%key_type:" پیشوند شده است. اگر هیچ نوعی مشخص نشود، کلید با نوع "user" به صورت پیش‌فرض پیوند داده می‌شود. برای اطلاعات بیشتر درباره توضیحات کلید (بخش شناساگرهای کلید - KEY IDENTIFIERS) به keyctl(1) مراجعه کنید.

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

اضافه‌شده در نسخه 256.

حالت LUKS را تحمیل می‌کند. هنگامی که از این حالت استفاده می‌شود، گزینه‌های زیر نادیده گرفته می‌شوند زیرا توسط هدر LUKS روی دستگاه ارائه می‌شوند: cipher=, hash=, size=.

اضافه‌شده در نسخه 186.

درایو BitLocker را رمزگشایی می‌کند. پارامترهای رمزنگاری توسط cryptsetup از هدر BitLocker استنباط می‌شوند.

اضافه‌شده در نسخه 246.

این دستگاه cryptsetup را به عنوان نیازمند به شبکه علامت‌گذاری می‌کند. این دستگاه پس از در دسترس قرار گرفتن شبکه راه‌اندازی می‌شود، مشابه با واحدهای systemd.mount(5) که با _netdev علامت‌گذاری شده‌اند. واحد سرویس برای راه‌اندازی این دستگاه، به جای قرارگیری بین cryptsetup-pre.target و cryptsetup.target, بین remote-fs-pre.target و remote-cryptsetup.target مرتب خواهد شد.

نکته: اگر این دستگاه برای یک نقطه اتصال (mount point) که در fstab(5) مشخص شده استفاده می‌شود، گزینه _netdev باید برای آن نقطه اتصال نیز استفاده شود. در غیر این صورت، ممکن است یک حلقه وابستگی ایجاد شود که در آن نقطه اتصال توسط local-fs.target فراخوانی می‌شود، در حالی که سرویس پیکربندی شبکه معمولاً تنها پس از سوار شدن سیستم‌فایل محلی راه‌اندازی می‌شود.

اضافه‌شده در نسخه 235.

این دستگاه به cryptsetup.target اضافه نخواهد شد. این بدان معناست که در هنگام بوت به طور خودکار بازگشایی نمی‌شود، مگر اینکه چیز دیگری آن را فراخوانی کند. به‌ویژه، اگر دستگاه برای یک نقطه اتصال استفاده شود، در طول بوت به طور خودکار بازگشایی خواهد شد، مگر اینکه خود نقطه اتصال نیز با noauto غیرفعال شده باشد.

اضافه‌شده در نسخه 186.

این دستگاه یک وابستگی سخت (ضروری) برای cryptsetup.target نخواهد بود. همچنان فراخوانی و راه‌اندازی خواهد شد، اما سیستم منتظر ظاهر شدن و بازگشایی دستگاه نخواهد ماند و در صورت ناموفق بودن این فرآیند، بوت شکست نخواهد خورد. توجه داشته باشید که سایر واحدهایی که به دستگاه بازگشایی‌شده وابسته هستند ممکن است همچنان با شکست مواجه شوند. به‌ویژه، اگر دستگاه برای یک نقطه اتصال استفاده شود، خود نقطه اتصال نیز باید گزینه nofail را داشته باشد، در غیر این صورت اگر دستگاه با موفقیت بازگشایی نشود، بوت با شکست مواجه خواهد شد. اگر یک فایل کلید و/یا یک header مشخص شده باشد، وابستگی‌ها به دایرکتوری‌های مربوطه آن‌ها نیز غیرکشنده (غیرحیاتی) خواهد بود، به طوری که پیاده کردن (unmount) دایرکتوری‌های مذکور باعث غیرفعال شدن واحد cryptset تولیدشده نخواهد شد.

اضافه‌شده در نسخه 186.

آفست شروع در دستگاه پس‌زمینه (backend)، بر حسب سکتورهای ۵۱۲ بایتی. این گزینه فقط برای دستگاه‌های plain کاربرد دارد.

اضافه‌شده در نسخه 220.

حالت رمزنگاری plain را تحمیل می‌کند.

اضافه‌شده در نسخه 186.

دستگاه بلاک رمزنگاری‌شده را در حالت فقط‌خواندنی راه‌اندازی می‌کند.

اضافه‌شده در نسخه 186.

عملیات رمزنگاری را با استفاده از همان پردازنده‌ای (CPU) انجام می‌دهد که عملیات ورودی/خروجی (IO) روی آن ثبت شده است. پیش‌فرض استفاده از یک صف کاری غیروابسته (unbound) است تا بار کاری رمزنگاری به طور خودکار بین پردازنده‌های موجود متعادل شود.

این به هسته لینوکس نسخه 4.0 یا جدیدتر نیاز دارد.

اضافه‌شده در نسخه 242.

برون‌سپاری نوشتن به یک رشته (thread) جداگانه پس از رمزنگاری را غیرفعال می‌کند. در برخی شرایط برون‌سپاری درخواست‌های نوشتن از رشته‌های رمزنگاری به یک رشته اختصاصی، کارایی را به میزان قابل‌توجهی کاهش می‌دهد. پیش‌فرض برون‌سپاری درخواست‌های نوشتن به یک رشته اختصاصی است، زیرا ارسال درخواست‌های نوشتن با استفاده از یک زمینه یکسان به نفع زمان‌بند CFQ است.

این به هسته لینوکس نسخه 4.0 یا جدیدتر نیاز دارد.

اضافه‌شده در نسخه 242.

صف کاری داخلی dm-crypt را دور می‌زند و درخواست‌های خواندن را به صورت همگام پردازش می‌کند. پیش‌فرض این است که این درخواست‌ها در صف قرار گیرند و به صورت ناهمگام پردازش شوند.

این به هسته لینوکس نسخه 5.9 یا جدیدتر نیاز دارد.

اضافه‌شده در نسخه 248.

صف کاری داخلی dm-crypt را دور می‌زند و درخواست‌های نوشتن را به صورت همگام پردازش می‌کند. پیش‌فرض این است که این درخواست‌ها در صف قرار گیرند و به صورت ناهمگام پردازش شوند.

این به هسته لینوکس نسخه 5.9 یا جدیدتر نیاز دارد.

اضافه‌شده در نسخه 248.

تعداد سکتورهای ۵۱۲ بایتی از داده‌های رمزنگاری‌شده که باید در ابتدا نادیده گرفته شوند را مشخص می‌کند. این گزینه با گزینه offset= از نظر شماره‌های سکتور مورد استفاده در محاسبه بردار اولیه (IV) متفاوت است. استفاده از offset= محاسبه IV را به همان میزان منفی جابجا می‌کند. بنابراین، اگر offset=n داده شود، سکتور n برای محاسبه IV شماره سکتور 0 را دریافت خواهد کرد. استفاده از skip= باعث می‌شود سکتور n نیز اولین سکتور دستگاه نگاشت‌شده باشد، اما شماره آن برای تولید IV همان n خواهد بود.

این گزینه فقط برای دستگاه‌های plain کاربرد دارد.

اضافه‌شده در نسخه 220.

اندازه کلید را بر حسب بیت مشخص می‌کند. برای مقادیر ممکن و مقدار پیش‌فرض این گزینه، cryptsetup(8) را ببینید.

اضافه‌شده در نسخه 186.

اندازه سکتور را بر حسب بایت مشخص می‌کند. برای مقادیر ممکن و مقدار پیش‌فرض این گزینه، cryptsetup(8) را ببینید.

اضافه‌شده در نسخه 240.

دستگاه بلاک رمزنگاری‌شده به عنوان یک دستگاه سواپ (swap) استفاده خواهد شد، و پس از راه‌اندازی دستگاه بلاک رمزنگاری‌شده، با استفاده از mkswap(8) به طور مناسب قالب‌بندی می‌شود. این گزینه مستلزم plain است. اضافه‌شده در نسخه 186.

از حالت رمزنگاری TrueCrypt استفاده می‌کند. هنگامی که از این حالت استفاده می‌شود، گزینه‌های زیر نادیده گرفته می‌شوند زیرا توسط هدر TrueCrypt روی دستگاه ارائه می‌شوند یا کاربردی ندارند: cipher=, hash=, keyfile-offset=, keyfile-size=, size=.

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

توجه داشته باشید که قالب TrueCrypt هم از عبارت عبور و هم از فایل‌های کلید برای اشتقاق یک گذرواژه برای حجم استفاده می‌کند. بنابراین، عبارت عبور و تمام فایل‌های کلید باید ارائه شوند. برای ارائه مسیر مطلق به تمام فایل‌های کلید از tcrypt-keyfile= استفاده کنید. هنگام استفاده از یک عبارت عبور خالی در ترکیب با یک یا چند فایل کلید، از "/dev/null" به عنوان فایل گذرواژه در فیلد سوم استفاده کنید.

اضافه‌شده در نسخه 206.

از حجم مخفی TrueCrypt استفاده می‌کند. این گزینه مستلزم tcrypt است.

این گزینه حجم مخفی را که درون حجم ارائه‌شده در فیلد دوم قرار دارد نگاشت می‌کند. لطفاً توجه داشته باشید که اگر به جای آن حجم بیرونی سوار شود، هیچ محافظتی برای حجم مخفی وجود ندارد. برای اطلاعات بیشتر در مورد این محدودیت، cryptsetup(8) را ببینید.

اضافه‌شده در نسخه 206.

مسیر مطلق به یک فایل کلید را برای استفاده در یک حجم TrueCrypt مشخص می‌کند. این گزینه مستلزم tcrypt است و می‌توان بیش از یک بار برای ارائه چندین فایل کلید از آن استفاده کرد.

برای آگاهی از رفتار عبارت عبور و فایل‌های کلید هنگام استفاده از حالت رمزنگاری TrueCrypt، مدخل مربوط به tcrypt را ببینید.

اضافه‌شده در نسخه 206.

از TrueCrypt در حالت رمزنگاری سیستمی استفاده می‌کند. این گزینه مستلزم tcrypt است.

اضافه‌شده در نسخه 206.

وجود یک حجم VeraCrypt را بررسی می‌کند. نرم‌افزار VeraCrypt یک انشعاب (fork) از TrueCrypt است که تا حد زیادی با آن سازگار است، اما از الگوریتم‌های اشتقاق کلید متفاوت و قوی‌تری استفاده می‌کند که بدون این فلگ قابل تشخیص نیستند. فعال کردن این گزینه ممکن است بازگشایی را به میزان قابل‌توجهی کند کند، زیرا اشتقاق کلید در VeraCrypt بسیار بیشتر از TrueCrypt زمان می‌برد. این گزینه مستلزم tcrypt است.

اضافه‌شده در نسخه 232.

یک مقدار سفارشی برای Personal Iteration Multiplier (PIM) مشخص می‌کند که می‌تواند در محدوده 0..2147468 برای حجم‌های استاندارد veracrypt و 0..65535 برای حجم‌های سیستمی veracrypt باشد. مقدار 0 به معنای پیش‌فرض VeraCrypt خواهد بود. این گزینه تنها زمانی مؤثر است که tcrypt-veracrypt تنظیم شده باشد.

توجه داشته باشید که VeraCrypt بسته به قدرت گذرواژه و الگوریتم درهم‌سازی (هش) استفاده‌شده برای اشتقاق کلید، حداقل مقدار مجاز PIM را اعمال می‌کند، با این حال veracrypt-pim= در برابر این محدوده‌ها بررسی نمی‌شود. برای اطلاعات بیشتر به مستندات Veracrypt Personal Iterations Multiplier[1] مراجعه کنید.

افزوده‌شده در نسخه 254.

مدت زمان مهلت (timeout) را برای درخواست گذرواژه مشخص می‌کند. اگر واحدی مشخص نشود، ثانیه در نظر گرفته می‌شود. واحدهای پشتیبانی‌شده عبارتند از s, ms, us, min, h, d. مقدار مهلت 0 به طور نامحدود منتظر می‌ماند (که پیش‌فرض است).

افزوده‌شده در نسخه 186.

دستگاه بلوکی رمزگذاری‌شده برای استفاده به عنوان /tmp/ آماده‌سازی خواهد شد؛ و با استفاده از mkfs(8) فرمت می‌شود. یک نوع سیستم فایل را به عنوان آرگومان می‌گیرد، مانند "ext4", "xfs" یا "btrfs". اگر آرگومانی مشخص نشود، مقدار پیش‌فرض "ext4" است. این گزینه مستلزم plain می‌باشد. افزوده‌شده در نسخه 186.

حداکثر تعداد دفعاتی که از کاربر برای گذرواژه درخواست می‌شود را مشخص می‌کند. مقدار پیش‌فرض 3 است. اگر روی 0 تنظیم شود، از کاربر به طور نامحدود برای گذرواژه درخواست می‌شود.

افزوده‌شده در نسخه 186.

یک آرگومان بولی می‌پذیرد که مقدار پیش‌فرض آن false است. اگر true باشد، هرگز به صورت تعاملی برای گذرواژه/PIN سؤالی پرسیده نمی‌شود. برای سیستم‌های بدون نمایشگر (headless) مفید است.

افزوده‌شده در نسخه 249.

اگر گذرواژه رمزگذاری از کنسول خوانده شود، برای جلوگیری از خطاهای تایپی باید دو بار وارد شود.

افزوده‌شده در نسخه 186.

کنترل می‌کند که آیا گذرواژه‌ها یا PINهای توکن امنیتی که از کنسول خوانده می‌شوند نمایش داده شوند (echo شوند) یا خیر. یک مقدار بولی یا رشته ویژه "masked" را می‌گیرد. مقدار پیش‌فرض password-echo=masked است.

اگر فعال باشد، نویسه‌های تایپ‌شده دقیقاً همان‌طور که هستند نمایش داده می‌شوند. اگر غیرفعال باشد، نویسه‌های تایپ‌شده به هیچ شکلی نمایش داده نمی‌شوند و کاربر هیچ بازخوردی در ورودی خود دریافت نمی‌کند. اگر روی "masked" تنظیم شود، به ازای هر نویسه تایپ‌شده یک ستاره ("*") نمایش داده می‌شود. صرف‌نظر از این‌که کدام حالت انتخاب شده باشد، اگر کاربر در هر زمان کلید تب ("↹") را بزند، یا قبل از وارد کردن هر داده دیگری کلید backspace ("⌫") را بفشارد، نمایش بازخورد (echo) خاموش می‌شود.

افزوده‌شده در نسخه 249.

کنترل می‌کند که آیا از حافظه نهان (کَش) برای گذرواژه‌ها یا PINهای توکن امنیتی استفاده شود یا خیر. یک مقدار بولی یا رشته ویژه "read-only" را می‌گیرد. مقدار پیش‌فرض "yes" است.

اگر روی "read-only" تنظیم شود، جاکلیدی (keyring) هسته قبل از درخواست تعاملی برای یافتن یک گذرواژه/PIN بررسی می‌شود. اگر روی "yes" تنظیم شود، علاوه بر بررسی جاکلیدی، هر گذرواژه/PIN که به صورت تعاملی وارد شده است در جاکلیدی با مهلت زمانی 2.5 دقیقه قبل از پاکسازی ذخیره می‌شود.

توجه داشته باشید که این گزینه برای توکن‌های امنیتی PKCS#11 مجاز نیست. دلیل آن این است که توکن‌های امنیتی PKCS#11 معمولاً طوری پیکربندی می‌شوند که پس از چندین بار وارد کردن PIN نامعتبر قفل شوند، بنابراین استفاده از حافظه نهان ممکن است ناخواسته توکن را قفل کند.

افزوده‌شده در نسخه 257.

یا مقدار ویژه "auto" یا یک RFC7512 PKCS#11 URI[2] را می‌پذیرد که به یک کلید خصوصی اشاره دارد که برای رمزگشایی کلید رمزگذاری‌شده مشخص‌شده در ستون سوم خط استفاده می‌شود. این برای بازگشایی قفل حجم‌های رمزگذاری‌شده از طریق توکن‌های امنیتی یا کارت‌های هوشمند سازگار با PKCS#11 مفید است. برای نمونه‌ای از نحوه راه‌اندازی این سازوکار برای بازگشایی قفل یک حجم LUKS2 با یک توکن امنیتی YubiKey به بخش زیر مراجعه کنید.

اگر به صورت "auto" مشخص شود، حجم باید از نوع LUKS2 باشد و متادیتای توکن امنیتی PKCS#11 را در بخش توکن JSON مربوط به LUKS2 خود داشته باشد. در این حالت، شناسه URI و کلید رمزگذاری‌شده به طور خودکار از هدر توکن JSON مربوط به LUKS2 خوانده می‌شوند. از systemd-cryptenroll(1) به عنوان ابزاری ساده برای ثبت توکن‌های امنیتی یا کارت‌های هوشمند PKCS#11 به روشی سازگار با "auto" استفاده کنید. در این حالت، ستون سوم خط باید خالی بماند (یعنی به صورت "-" مشخص شود).

شناسه URI مشخص‌شده می‌تواند مستقیماً به یک کلید خصوصی ذخیره‌شده روی یک توکن یا متناوباً فقط به یک اسلات یا توکن اشاره کند، که در این صورت جستجویی برای یافتن یک کلید خصوصی مناسب انجام خواهد شد. در این حالت، اگر چندین شیء مناسب یافت شود، توکن رد می‌شود. فایل کلید پیکربندی‌شده در ستون سوم خط به همان صورتی که هست (یعنی در فرمت باینری، پردازش‌نشده) استفاده می‌شود. کلید رمزگشایی‌شده حاصل (برای RSA) یا راز مشترک مشتق‌شده (برای ECC) قبل از اینکه برای بازگشایی قفل حجم LUKS استفاده شود، کدگذاری Base64 می‌شود.

از systemd-cryptenroll --pkcs11-token-uri=list برای فهرست کردن تمام توکن‌های امنیتی PKCS#11 مناسب که در حال حاضر متصل هستند، همراه با شناسه‌های URI آن‌ها استفاده کنید.

توجه داشته باشید که بسیاری از توکن‌های امنیتی جدیدتر که ممکن است به عنوان توکن امنیتی PKCS#11 استفاده شوند، معمولاً استاندارد جدیدتر و ساده‌تر FIDO2 را نیز پیاده‌سازی می‌کنند. استفاده از fido2-device= (توضیح داده شده در زیر) را برای ثبت آن از طریق FIDO2 در نظر بگیرید. توجه داشته باشید که یک توکن امنیتی ثبت‌شده از طریق PKCS#11 نمی‌تواند برای بازگشایی قفل حجم از طریق FIDO2 استفاده شود، مگر اینکه از طریق FIDO2 نیز ثبت شده باشد، و برعکس.

افزوده‌شده در نسخه 245.

یا مقدار ویژه "auto" یا مسیر یک گره دستگاهی "hidraw" (مانند /dev/hidraw1) را می‌پذیرد که به یک توکن امنیتی FIDO2 اشاره دارد که افزونه "hmac-secret" را پیاده‌سازی می‌کند (اکثر توکن‌های امنیتی سخت‌افزاری فعلی آن را دارند). برای نمونه‌ای از نحوه راه‌اندازی این سازوکار برای بازگشایی قفل یک حجم رمزگذاری‌شده با یک توکن امنیتی FIDO2 به بخش زیر مراجعه کنید.

اگر به صورت "auto" مشخص شود، دستگاه توکن FIDO2 هنگام اتصال به طور خودکار کشف می‌شود.

بازگشایی قفل حجم با FIDO2 برای عملکرد خود نیاز دارد که یک هش شناسه کلاینت (CID) از طریق fido2-cid= (زیر را ببینید) پیکربندی شود و کلیدی به قابلیت HMAC توکن امنیتی ارسال شود (پیکربندی‌شده در ستون سوم خط). اگر پیکربندی نشود و حجم از نوع LUKS2 باشد، در عوض CID و کلید از متادیتای توکن JSON مربوط به LUKS2 خوانده می‌شوند. از systemd-cryptenroll(1) به عنوان ابزاری ساده برای ثبت توکن‌های امنیتی FIDO2 برای حجم‌های LUKS2 استفاده کنید.

از systemd-cryptenroll --fido2-device=list برای فهرست کردن تمام توکن‌های امنیتی FIDO2 مناسب که در حال حاضر متصل هستند، همراه با گره‌های دستگاهی آن‌ها استفاده کنید.

این گزینه سازوکار زیر را پیاده‌سازی می‌کند: کلید پیکربندی‌شده از طریق تابع درهم‌سازی کلیددار HMAC که دستگاه FIDO2 پیاده‌سازی می‌کند، و با یک کلید مخفی تعبیه‌شده در دستگاه کلیدگذاری شده است، هش می‌شود. مقدار هش حاصل با Base64 کدگذاری شده و برای بازگشایی قفل حجم LUKS2 استفاده می‌شود. از آنجایی که استخراج کلید مخفی از توکن سخت‌افزاری نباید امکان‌پذیر باشد، با در دست داشتن کلید پیکربندی‌شده — بدون در دست داشتن توکن سخت‌افزاری — بازیابی کلید هش‌شده نباید ممکن باشد.

توجه داشته باشید که بسیاری از توکن‌های امنیتی که FIDO2 را پیاده‌سازی می‌کنند، PKCS#11 را نیز پیاده‌سازی می‌کنند که برای بازگشایی قفل حجم‌ها از طریق گزینه pkcs11-uri= که در بالا توضیح داده شد مناسب است. معمولاً استاندارد جدیدتر و ساده‌تر FIDO2 ترجیح داده می‌شود.

افزوده‌شده در نسخه 248.

یک شناسه کلاینت (CID) با کدگذاری Base64 از FIDO2 را برای استفاده در عملیات بازگشایی قفل FIDO2 می‌گیرد. اگر مشخص شود، اما fido2-device= مشخص نشده باشد، fido2-device=auto استنباط می‌شود. اگر fido2-device= استفاده شود اما fido2-cid= مشخص نشده باشد، حجم باید از نوع LUKS2 باشد و CID از هدر توکن JSON مربوط به LUKS2 خوانده می‌شود. از systemd-cryptenroll(1) برای ثبت یک توکن FIDO2 در هدر LUKS2 به گونه‌ای سازگار با این حالت خودکار استفاده کنید.

افزوده‌شده در نسخه 248.

یک رشته می‌گیرد و Relying Party (rp) در FIDO2 را برای عملیات بازگشایی قفل FIDO2 پیکربندی می‌کند. اگر مشخص نشود، "io.systemd.cryptsetup" استفاده می‌شود، مگر اینکه هدر توکن JSON مربوط به LUKS2 حاوی مقدار متفاوتی باشد. معمولاً نباید نیازی به بازنویسی این مقدار باشد.

افزوده‌شده در نسخه 248.

کنترل می‌کند که آیا هنگام بازگشایی قفل حجم، کاربر ملزم به وارد کردن PIN باشد یا خیر (قابلیت "clientPin" در FIDO2). این گزینه فقط در حالت دستی اعمال می‌شود، یعنی زمانی که گزینه fido2-cid= تنظیم شده باشد. مقدار پیش‌فرض نه true است و نه false، بلکه رفتار v248 است، یعنی: ابتدا بدون PIN تلاش می‌شود، اما اگر توکن گزارش دهد که PIN لازم است، دوباره با درخواست PIN تلاش می‌شود.

افزوده‌شده در نسخه 257.

کنترل می‌کند که آیا هنگام بازگشایی قفل حجم، کاربر ملزم به تایید حضور (لمس فیزیکی توکن، قابلیت "up" در FIDO2) باشد یا خیر. این گزینه فقط در حالت دستی اعمال می‌شود، یعنی زمانی که گزینه fido2-cid= تنظیم شده باشد. مقدار پیش‌فرض نه true است و نه false، بلکه رفتار v248 است، یعنی: ابتدا بدون UP تلاش می‌شود، اما اگر توکن گزارش دهد که UP لازم است، دوباره با فعال بودن UP تلاش می‌شود.

افزوده‌شده در نسخه 257.

کنترل می‌کند که آیا هنگام بازگشایی قفل حجم، اعتبارسنجی کاربر (قابلیت "uv" در FIDO2) الزامی باشد یا خیر. این گزینه فقط در حالت دستی اعمال می‌شود، یعنی زمانی که گزینه fido2-cid= تنظیم شده باشد. مقدار پیش‌فرض نه true است و نه false، بلکه رفتار v248 است، یعنی: کلاً از پیکربندی UV صرف‌نظر می‌شود.

افزوده‌شده در نسخه 257.

یا مقدار ویژه "auto" یا مسیر یک گره دستگاهی (مانند /dev/tpmrm0) را می‌پذیرد که به یک تراشه امنیتی TPM2 اشاره دارد. برای نمونه‌ای از نحوه راه‌اندازی این سازوکار برای بازگشایی قفل یک حجم رمزگذاری‌شده با تراشه TPM2 به بخش زیر مراجعه کنید.

از tpm2-pcrs= (زیر را ببینید) برای پیکربندی مجموعه‌ای از PCRهای TPM2 جهت متصل کردن بازگشایی قفل حجم به آن‌ها استفاده کنید. از systemd-cryptenroll(1) به عنوان ابزاری ساده برای ثبت تراشه‌های امنیتی TPM2 در حجم‌های LUKS2 استفاده کنید.

اگر به صورت "auto" مشخص شود، دستگاه TPM2 به طور خودکار کشف می‌شود. از systemd-cryptenroll --tpm2-device=list برای فهرست کردن تمام دستگاه‌های TPM2 مناسب در دسترس، همراه با گره‌های دستگاهی آن‌ها استفاده کنید.

این گزینه سازوکار زیر را پیاده‌سازی می‌کند: هنگام ثبت یک دستگاه TPM2 از طریق systemd-cryptenroll روی یک حجم LUKS2، یک کلید تصادفی برای بازگشایی قفل حجم روی میزبان ایجاد شده و در تراشه TPM2 بارگذاری می‌شود، جایی که با یک جفت‌کلید نامتقارن "اصلی" مشتق‌شده از کلید "seed" داخلی TPM2 رمزگذاری می‌شود. نه کلید seed و نه کلید اصلی هرگز اجازه خروج از تراشه TPM2 را ندارند — با این حال، کلید تصادفی که اکنون رمزگذاری شده است، می‌تواند خارج شود. این کلید در هدر توکن JSON مربوط به حجم LUKS2 ذخیره می‌شود. هنگام بازگشایی قفل حجم رمزگذاری‌شده، جفت‌کلید اصلی دوباره روی تراشه TPM2 تولید می‌شود (که تا زمانی که کلید seed تراشه به درستی توسط تراشه TPM2 نگهداری شود کار می‌کند)، و سپس برای رمزگشایی (روی تراشه TPM2) کلید رمزگذاری‌شده موجود در هدر توکن JSON مربوط به حجم LUKS2 که در زمان ثبت در آنجا ذخیره شده بود، استفاده می‌شود. کلید رمزگشایی‌شده حاصل سپس برای باز کردن قفل حجم استفاده می‌شود. هنگامی که کلید تصادفی رمزگذاری می‌شود، مقادیر فعلی PCRهای انتخاب‌شده (زیر را ببینید) در عملیات لحاظ می‌شوند، به طوری که وضعیت‌های متفاوت PCR به کلیدهای رمزگذاری‌شده متفاوتی منجر می‌شوند و کلید رمزگشایی‌شده تنها در صورتی قابل بازیابی است که همان وضعیت PCR دوباره ایجاد شود.

افزوده‌شده در نسخه 248.

فهرستی جداشده با "+" از شناسه‌های عددی TPM2 PCR (یعنی «Platform Configuration Register») را می‌پذیرد تا بازگشایی قفل حجم TPM2 را به آن‌ها متصل (bind) کند. این گزینه تنها زمانی مفید است که متادیتای ثبت TPM2 از قبل در هدر توکن JSON مربوط به LUKS2 وجود نداشته باشد (روشی که systemd-cryptenroll آن را در آنجا می‌نویسد). در صورت عدم استفاده (و اگر متادیتایی در هدر توکن JSON مربوط به LUKS2 آن را تعریف نکرده باشد)، به طور پیش‌فرض روی فهرستی با یک ورودی تکی تنظیم می‌شود: PCR 7. یک رشته خالی اختصاص دهید تا سیاستی رمزگذاری شود که کلید را به هیچ PCR متصل نمی‌کند، و کلید را صرف‌نظر از وضعیت فعلی PCR برای برنامه‌های محلی در دسترس قرار می‌دهد.

افزوده‌شده در نسخه 248.

یک آرگومان بولی می‌پذیرد که مقدار پیش‌فرض آن "false" است. کنترل می‌کند که آیا علاوه بر PCRها، بازگشایی قفل حجم TPM2 به یک PIN نیز متصل شود یا خیر. به همین ترتیب، این گزینه تنها زمانی مفید است که متادیتای ثبت TPM2 در دسترس نباشد.

افزوده‌شده در نسخه 251.

یک مسیر مطلق به فایل امضای JSON مربوط به TPM2 PCR را می‌گیرد، همان‌طور که توسط ابزار systemd-measure(1) تولید می‌شود. این اجازه می‌دهد تا حجم‌های LUKS2 به هر مقادیر PCR که برای آن‌ها امضای معتبری منطبق با کلید عمومی مشخص‌شده در زمان ثبت کلید ارائه شود، قفل شوند. برای جزئیات مربوط به ثبت کلیدهای عمومی TPM2 PCR به systemd-cryptenroll(1) مراجعه کنید. اگر این گزینه مشخص نشده باشد اما تلاشی برای بازگشایی قفل یک حجم LUKS2 با یک ثبت TPM2 PCR امضاشده صورت گیرد، یک فایل امضای مناسب با نام tpm2-pcr-signature.json به ترتیب در /etc/systemd/، /run/systemd/ و /usr/lib/systemd/ جستجو می‌شود.

افزوده‌شده در نسخه 252.

یک مسیر مطلق به فایل خط‌مشی pcrlock مربوط به TPM2 را می‌گیرد، همان‌طور که توسط ابزار systemd-pcrlock(8) تولید می‌شود. این اجازه می‌دهد تا حجم‌های LUKS2 به یک خط‌مشی محلی از مقادیر مجاز PCR همراه با متغیرها قفل شوند. برای جزئیات ثبت خط‌مشی‌های pcrlock مربوط به TPM2 به systemd-cryptenroll(1) مراجعه کنید. اگر این گزینه مشخص نشود اما تلاشی برای بازگشایی قفل یک حجم LUKS2 با یک ثبت pcrlock مربوط به TPM2 صورت گیرد، یک فایل امضای مناسب با نام pcrlock.json به ترتیب در /run/systemd/ و /var/lib/systemd/ جستجو می‌شود.

افزوده‌شده در نسخه 255.

کنترل می‌کند که آیا کلید حجم مربوط به حجم رمزگذاری‌شده در یک PCR از TPM2 اندازه‌گیری (سنجش) شود یا خیر. اگر روی "no" تنظیم شود (که پیش‌فرض است) هیچ افزونه PCR انجام نمی‌شود. اگر روی "yes" تنظیم شود، کلید حجم در PCR 15 اندازه‌گیری می‌شود. اگر روی یک عدد صحیح ده‌دهی در محدوده 0...23 تنظیم شود، کلید حجم در PCR مشخص‌شده سنجیده می‌شود. کلید حجم به همراه نام حجم فعال‌شده و UUID آن اندازه‌گیری می‌شود. این قابلیت به ویژه برای حجم رمزگذاری‌شده پشتیبان سیستم فایل ریشه مفید است، زیرا پس از آن اجازه می‌دهد اشیاء بعدی TPM به طور امن به سیستم فایل ریشه و در نتیجه به نصب خاص سیستم متصل شوند.

افزوده‌شده در نسخه 253.

یک یا چند بانک PCR از TPM2 را برای سنجش کلید حجم در آن، همان‌طور که با tpm2-measure-pcr= در بالا پیکربندی شده است، انتخاب می‌کند. ممکن است چندین بانک مشخص شود که با نویسه دونقطه (:) از هم جدا می‌شوند. در صورت عدم تعیین، بانک‌های موجود و استفاده‌شده را به طور خودکار تعیین می‌کند. یک نام چکیده پیام (مانند "sha1", "sha256", ...) را به عنوان آرگومان برای شناسایی بانک انتظار دارد.

افزوده‌شده در نسخه 253.

کنترل می‌کند که آیا اطلاعات مربوط به اسلات کلید LUKS استفاده‌شده برای بازگشایی قفل در یک نمایه غیرفرار TPM2 (یعنی nvindex در حالت PCR) اندازه‌گیری شود یا خیر. یک آرگومان بولی یا یک نام NvPCR را می‌پذیرد. اگر روی false یا یک رشته خالی تنظیم شود (که پیش‌فرض است) هیچ توسعه‌ای در TPM2 nvindex انجام نمی‌شود، در غیر این صورت اطلاعات اسلات کلید در یک nvindex با نام مشخص‌شده اندازه‌گیری می‌شود که در صورت نیاز تخصیص می‌یابد. اگر روی true تنظیم شود، مقدار پیش‌فرض توصیه‌شده "cryptsetup" به عنوان NvPCR انتخاب می‌شود. نمایه اسلات و سازوکار بازگشایی استفاده‌شده (یعنی "tpm2", "fido2", "pkcs11") همراه با نام حجم فعال‌شده و UUID آن اندازه‌گیری می‌شوند.

افزوده‌شده در نسخه 259.

حداکثر مدت زمان انتظار برای حاضر شدن دستگاه‌های امنیتی پیکربندی‌شده (یعنی FIDO2, PKCS#11, TPM2) را مشخص می‌کند. یک مقدار زمانی بر حسب ثانیه می‌گیرد (اما سایر واحدهای زمانی نیز می‌توانند مشخص شوند، برای فرمت‌های پشتیبانی‌شده به systemd.time(7) مراجعه کنید). مقدار پیش‌فرض 30s است. هنگامی که مهلت مشخص‌شده به پایان برسد، احراز هویت از طریق گذرواژه امتحان می‌شود. توجه داشته باشید که این مهلت زمانی برای انتظار جهت حاضر شدن دستگاه امنیتی اعمال می‌شود — برای اعلان درخواست PIN دستگاه (در صورت نیاز) یا موارد مشابه اعمال نمی‌شود. مقدار 0 را برای خاموش کردن مهلت زمانی و انتظار همیشگی ارسال کنید.

افزوده‌شده در نسخه 250.

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

افزوده‌شده در نسخه 246.

مشخص می‌کند که systemd چه مدت باید منتظر ظاهر شدن یک دستگاه بلوکی بماند قبل از اینکه از آن ورودی صرف‌نظر کند. آرگومان، زمانی بر حسب ثانیه یا واحدهای صریحاً مشخص‌شده از "s", "min", "h", "ms" است.

افزوده‌شده در نسخه 216.

این دستگاه بلوکی رمزگذاری‌شده را در initrd راه‌اندازی می‌کند، مشابه واحدهای systemd.mount(5) که با x-initrd.mount علامت‌گذاری شده‌اند.

اگرچه علامت‌گذاری ورودی سوار کردن (mount) سیستم فایل ریشه با x-initrd.mount ضروری نیست، اما x-initrd.attach همچنان برای دستگاه بلوکی رمزگذاری‌شده حاوی سیستم فایل ریشه توصیه می‌شود، زیرا در غیر این صورت systemd در حین خاموش شدن عادی سیستم در حالی که هنوز در حال استفاده است، تلاش خواهد کرد دستگاه را جدا کند. با این گزینه، دستگاه همچنان جدا می‌شود اما بعداً پس از پیاده شدن (unmount) سیستم فایل ریشه صورت می‌گیرد.

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

افزوده‌شده در نسخه 245.

هش مورد انتظار کلید حجم را تثبیت می‌کند.

در موارد خاص، مثلاً برای حجم‌های LUKS که کلید در TPM2 مهر و موم (seal) شده است، ممکن است برای ارائه این تضمین که حجم در حال اتصال همان حجمی است که قبلاً ایجاد شده بود، لازم باشد. fixate-volume-key= می‌تواند برای تنظیم هش مورد انتظار کلید حجم و رد اتصال حجم در صورت داشتن هش متفاوت استفاده شود. هش مورد انتظار با خلاصه‌ای مطابقت دارد که هنگام استفاده از tpm2-measure-pcr= در بانک sha256 PCR تراشه TPM2 اندازه‌گیری می‌شود.

برای حجم‌های LUKS تازه ایجادشده، هش مورد انتظار می‌تواند توسط systemd-repart(8) تولید شود. برای جزئیات بیشتر، توضیحات EncryptedVolume= را در repart.d(5) ببینید.

افزوده‌شده در نسخه 260.

NUL RANDOM /cryptsetup/ VOLUME

\0d7067f78d9827418/cryptsetup/myvol

luks       UUID=2505567a-9e27-4efe-a4d5-15ad146c258b
swap       /dev/sda7       /dev/urandom       swap
truecrypt  /dev/sda2       /etc/container_password  tcrypt
hidden     /mnt/tc_hidden  /dev/null    tcrypt-hidden,tcrypt-keyfile=/etc/keyfile
external   /dev/sda3       keyfile:LABEL=keydev keyfile-timeout=10s,cipher=xchacha12\,aes-adiantum-plain64

# SPDX-License-Identifier: MIT-0
# Destroy any old key on the Yubikey (careful!)
ykman piv reset
# Generate a new private/public key pair on the device, store the public key in
# 'pubkey.pem'.
ykman piv generate-key -a RSA2048 9d pubkey.pem
# Create a self-signed certificate from this public key, and store it on the
# device. The "subject" should be an arbitrary user-chosen string to identify
# the token with.
ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem
# We do not need the public key anymore, let's remove it. Since it is not
# security sensitive we just do a regular "rm" here.
rm pubkey.pem
# Enroll the freshly initialized security token in the LUKS2 volume. Replace
# /dev/sdXn by the partition to use (e.g. /dev/sda1).
sudo systemd-cryptenroll --pkcs11-token-uri=auto /dev/sdXn
# Test: Let's run systemd-cryptsetup to test if this all worked.
sudo systemd-cryptsetup attach mytest /dev/sdXn none pkcs11-uri=auto
# If that worked, let's now add the same line persistently to /etc/crypttab,
# for the future. We do not want to use the (unstable) /dev/sdX name, so let's
# figure out a stable link:
udevadm info -q symlink -r /dev/sdXn
# Now add the line using the by-uuid symlink to /etc/crypttab:
sudo bash -c 'echo "mytest /dev/disk/by-uuid/... none pkcs11-uri=auto" >>/etc/crypttab'
# Depending on your distribution and encryption setup, you may need to manually
# regenerate your initramfs to be able to use a Yubikey / PKCS#11 token to
# unlock the partition during early boot.
# More information at https://unix.stackexchange.com/a/705809
# On Fedora based systems:
sudo dracut --force
# On Debian based systems:
sudo update-initramfs -u

•ما از RSA2048 استفاده می‌کنیم که طولانی‌ترین اندازه کلیدی است که Yubikeyهای فعلی پشتیبانی می‌کنند

•ما از اسلات کلید 9d در Yubikey استفاده می‌کنیم، زیرا ظاهراً این اسلات کلیدی است که باید برای اهداف رمزگشایی استفاده شود، به Yubico PIV certificate slots[3] مراجعه کنید.

# SPDX-License-Identifier: MIT-0
# Enroll the security token in the LUKS2 volume. Replace /dev/sdXn by the
# partition to use (e.g. /dev/sda1).
sudo systemd-cryptenroll --fido2-device=auto /dev/sdXn
# Test: Let's run systemd-cryptsetup to test if this worked.
sudo systemd-cryptsetup attach mytest /dev/sdXn none fido2-device=auto
# If that worked, let's now add the same line persistently to /etc/crypttab,
# for the future. We do not want to use the (unstable) /dev/sdX name, so let's
# figure out a stable link:
udevadm info -q symlink -r /dev/sdXn
# Now add the line using the by-uuid symlink to /etc/crypttab:
sudo bash -c 'echo "mytest /dev/disk/by-uuid/... none fido2-device=auto" >>/etc/crypttab'
# Depending on your distribution and encryption setup, you may need to manually
# regenerate your initramfs to be able to use a FIDO2 device to unlock the
# partition during early boot.
# More information at https://unix.stackexchange.com/a/705809
# On Fedora based systems:
sudo dracut --force
# On Debian based systems:
sudo update-initramfs -u

# SPDX-License-Identifier: MIT-0
# Enroll the TPM2 security chip in the LUKS2 volume, and bind it to PCR 7
# only. Replace /dev/sdXn by the partition to use (e.g. /dev/sda1).
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdXn
# Test: Let's run systemd-cryptsetup to test if this worked.
sudo systemd-cryptsetup attach mytest /dev/sdXn none tpm2-device=auto
# If that worked, let's now add the same line persistently to /etc/crypttab,
# for the future. We do not want to use the (unstable) /dev/sdX name, so let's
# figure out a stable link:
udevadm info -q symlink -r /dev/sdXn
# Now add the line using the by-uuid symlink to /etc/crypttab:
sudo bash -c 'echo "mytest /dev/disk/by-uuid/... none tpm2-device=auto" >>/etc/crypttab'
# And now let's check that automatic unlocking works:
sudo systemd-cryptsetup detach mytest
sudo systemctl daemon-reload
sudo systemctl start cryptsetup.target
systemctl is-active systemd-cryptsetup@mytest.service
# Once we have the device which will be unlocked automatically, we can use it.
# Usually we would create a file system and add it to /etc/fstab:
sudo mkfs.ext4 /dev/mapper/mytest
# This prints a 'Filesystem UUID', which we can use as a stable name:
sudo bash -c 'echo "/dev/disk/by-uuid/... /var/mytest ext4 defaults,x-systemd.mkdir 0 2" >>/etc/fstab'
# And now let's check that the mounting works:
sudo systemctl daemon-reload
sudo systemctl start /var/mytest
systemctl status /var/mytest
# Depending on your distribution and encryption setup, you may need to manually
# regenerate your initramfs to be able to use a TPM2 security chip to unlock
# the partition during early boot.
# More information at https://unix.stackexchange.com/a/705809
# On Fedora based systems:
sudo dracut --force
# On Debian based systems:
sudo update-initramfs -u