LUKS2 và cryptsetup: Mã hóa ổ đĩa Linux an toàn cho production

LUKS2 không chỉ là một mật khẩu đặt trước ổ đĩa. Nó là lớp quản lý metadata và nhiều keyslot bao quanh volume key mà dm-crypt dùng để mã hóa block device. Triển khai production đúng cần bắt đầu từ threat model, bảo vệ header backup, xoay khóa theo quy trình có kiểm chứng, thiết kế mở khóa lúc boot và diễn tập recovery trước khi có sự cố.

Bài viết bám theo tài liệu chính thức của cryptsetup, Cryptsetup FAQ và dm-crypt trong Linux kernel. Cú pháp, default và tích hợp initramfs khác nhau theo phiên bản cryptsetup/distribution; luôn đọc man page trên chính hệ thống sẽ vận hành.

1. LUKS2 bảo vệ điều gì?

Threat model phải nêu rõ đối thủ có thiết bị đã tắt, có quyền truy cập lúc máy chạy, có thể sửa boot chain hay đã lấy được credential quản trị. Full-disk encryption mạnh nhất với data at rest; nó không thay access control, Secure Boot/measured boot, vá lỗi, endpoint security hay backup.

2. Volume key, keyslot và passphrase

dm-crypt dùng volume key để mã hóa dữ liệu. LUKS không mã hóa toàn bộ dữ liệu trực tiếp bằng passphrase người dùng; mỗi keyslot dùng một key được suy dẫn từ passphrase hoặc secret để bọc volume key. Vì vậy nhiều passphrase/token có thể mở cùng volume mà không cần mã hóa lại toàn bộ dữ liệu.

• Header: metadata định dạng, tham số và thông tin keyslot.
• Keyslot: một cách được phép để lấy volume key.
• Volume key: bí mật thực sự dùng cho mapping dm-crypt.
• Mapped device: block device plaintext dưới /dev/mapper/... khi volume đang mở.

Xóa một keyslot chỉ thu hồi cách mở khóa đó; dữ liệu không được mã hóa lại bằng volume key mới. Ngược lại, sao chép nguyên image LUKS sang nhiều máy cũng sao chép volume key—đổi passphrase sau đó không làm các bản clone có volume key riêng.

3. Kiểm kê trước khi chạm vào block device

lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS
findmnt
cryptsetup --version
cryptsetup isLuks /dev/disk/by-id/DEVICE && echo "LUKS detected"
cryptsetup luksDump /dev/disk/by-id/DEVICE

Dùng đường dẫn ổn định trong /dev/disk/by-id hoặc UUID thay cho tên /dev/sdX dễ đổi sau reboot. Xác nhận backup và maintenance window, rồi ghi lại partition table, UUID, boot dependency và owner. Không copy lệnh định dạng khi chưa đối chiếu serial/size/mount point bằng ít nhất hai nguồn.

4. Tạo volume mới: thao tác phá dữ liệu

Cảnh báo: luksFormat ghi metadata lên thiết bị và có thể làm mất quyền truy cập dữ liệu hiện có. Ví dụ sau chỉ dành cho block device rỗng trong lab hoặc thiết bị đã được xác nhận sẽ xóa.

# CHỈ dùng với thiết bị rỗng đã xác minh chính xác
sudo cryptsetup --type luks2 luksFormat /dev/disk/by-id/EMPTY-LAB-DEVICE
sudo cryptsetup open /dev/disk/by-id/EMPTY-LAB-DEVICE app_crypt

# Tạo filesystem trên mapped device, không phải trên raw LUKS device
sudo mkfs.ext4 /dev/mapper/app_crypt
sudo mount /dev/mapper/app_crypt /srv/app

Không cargo-cult cipher, key size hay PBKDF từ một blog cũ. Default cryptsetup thay đổi theo phiên bản và policy distribution để theo kịp phần cứng. Nếu compliance yêu cầu tham số cụ thể, benchmark trên phần cứng mục tiêu, kiểm tra hỗ trợ kernel/initramfs và lưu quyết định kiến trúc. luksDump cho phép audit cấu hình thực tế mà không in passphrase.

5. Passphrase và key file là hai loại bí mật khác nhau

Passphrase cần đủ entropy, duy nhất và chống đoán offline; độ dài có ý nghĩa hơn biến thể ký tự dễ đoán. Key file có thể đạt entropy cao nhưng rủi ro nằm ở nơi lưu và cách cấp quyền. Nếu key file nằm plaintext trên cùng máy và cùng storage không được bảo vệ, lợi ích trước kẻ trộm thiết bị có thể biến mất.

• Không đặt secret trực tiếp trong command line, shell history, unit file hay ticket.
• Giới hạn quyền file và thư mục; tránh để backup agent/log collector thu nhầm.
• Tách khóa vận hành, khóa recovery và automation identity.
• Dùng secret store/TPM/token theo threat model, nhưng luôn có recovery path độc lập đã test.
• Không gửi strace chứa luồng nhập secret vào hệ thống hỗ trợ công khai.

6. Quy trình thêm, kiểm tra rồi mới thu hồi khóa

# Thêm passphrase mới; cần xác thực bằng key đang hợp lệ
sudo cryptsetup luksAddKey /dev/disk/by-id/DEVICE

# Kiểm tra passphrase mới mà không tạo mapping lâu dài
sudo cryptsetup open --test-passphrase /dev/disk/by-id/DEVICE

# Chỉ sau khi test và xác nhận recovery key khác còn hoạt động
sudo cryptsetup luksRemoveKey /dev/disk/by-id/DEVICE

sudo cryptsetup luksDump /dev/disk/by-id/DEVICE

Rotation an toàn là add → test → cập nhật escrow/automation → kiểm tra boot/recovery → remove old key. Không dùng luksKillSlot theo số slot một cách mù quáng; nhầm slot cuối còn hoạt động có thể khóa vĩnh viễn volume. Với fleet, duy trì inventory keyslot/token owner và bằng chứng rotation thay vì lưu passphrase trong inventory.

7. Header backup là bắt buộc, nhưng cực kỳ nhạy cảm

sudo cryptsetup luksHeaderBackup \
  /dev/disk/by-id/DEVICE \
  --header-backup-file /secure-staging/host-volume.luks2-header

sudo chmod 0600 /secure-staging/host-volume.luks2-header
sha256sum /secure-staging/host-volume.luks2-header

Đưa file header backup sang kho mã hóa, kiểm soát truy cập, tách khỏi thiết bị nguồn và không để bản staging lâu hơn cần thiết. Header backup chứa keyslot đã mã hóa: người có file này và passphrase hợp lệ tương ứng có thể nhắm tới dữ liệu volume. Nó cũng có thể khôi phục một keyslot cũ đã bị thu hồi nếu backup lịch sử vẫn còn, nên rotation phải đi cùng policy quản lý phiên bản header backup.

LUKS2 có metadata dự phòng tốt hơn LUKS1 nhưng không miễn nhiễm với overwrite, lỗi thiết bị hay thao tác sai. Header backup không thay full data backup: nó chỉ giúp khôi phục metadata/keyslot, không tái tạo block dữ liệu đã mất.

8. Restore header là quy trình cứu hộ, không phải bước thử tùy tiện

Không chạy trực tiếp trên production đang khỏe. Header restore ghi đè metadata và keyslot hiện tại. Trước tiên phải chụp backup trạng thái hiện tại, xác minh đúng device/UUID, làm việc trên clone khi có thể và tuân theo runbook được duyệt.

# Kiểm tra file header theo cơ chế detached header trên bản clone/lab
sudo cryptsetup --header host-volume.luks2-header \
  open --test-passphrase /dev/disk/by-id/RECOVERY-CLONE

# Chỉ trong phiên recovery đã xác minh đầy đủ
sudo cryptsetup luksHeaderRestore \
  /dev/disk/by-id/RECOVERY-CLONE \
  --header-backup-file host-volume.luks2-header

Luôn lưu header hiện tại trước restore, kể cả khi nghi nó hỏng. Xác minh checksum, provenance, thời điểm và volume UUID của backup. Sau restore, chỉ mount read-only trước, kiểm tra filesystem rồi mới quyết định bước ghi tiếp theo.

9. Mở khóa lúc boot và initramfs

Root volume cần được mở trong initramfs; data volume thường được mô tả bằng /etc/crypttab và mount qua /etc/fstab hoặc systemd mount unit. Tên option và lệnh tái tạo initramfs khác giữa Debian/Ubuntu, RHEL/Fedora, SUSE và các distro khác.

• Dùng UUID ổn định, không phụ thuộc thứ tự thiết bị.
• Xác định hành vi khi secret store/TPM/network không sẵn sàng: timeout, console recovery hay fail closed.
• Không để network unlock mở rộng bề mặt quản trị ngoài ý muốn.
• Giữ recovery key offline và diễn tập trên console thật, kể cả remote console.
• Sau mọi thay đổi key/token/crypttab/initramfs, reboot có kiểm soát khi vẫn còn đường quay lại.

Một volume đang mở trước reboot không chứng minh boot path mới hoạt động. Đừng thu hồi khóa cũ cho đến khi image initramfs mới, enrollment mới và recovery path đều đã được kiểm tra.

10. Suspend, hibernate, swap và runtime exposure

Khi máy đang chạy, khóa có thể tồn tại trong kernel keyring/memory và plaintext đi qua mapped device. Screen lock không tương đương đóng volume. Với laptop/server có hibernate, swap phải nằm trong mô hình mã hóa phù hợp vì RAM image có thể chứa secret. Crash dump và hibernation image cũng cần policy riêng.

Cold boot, DMA, evil-maid và boot-chain tampering nằm ngoài lời hứa đơn giản “ổ đã mã hóa”. Tùy threat model, kết hợp Secure Boot, measured boot, TPM policy, IOMMU, khóa firmware và kiểm soát vật lý. Auto-unlock cải thiện availability nhưng có thể giảm mức bảo vệ khi kẻ tấn công lấy cả máy nguyên trạng.

11. Discard/TRIM và integrity là quyết định có đánh đổi

Cho discard đi qua lớp mã hóa có thể giúp SSD reclaim space và ổn định hiệu năng, nhưng làm lộ pattern sector nào đang được sử dụng hoặc thay đổi. Không bật chỉ vì một template có discard; đánh giá workload, thiết bị, threat model và khuyến nghị distribution.

dm-crypt cơ bản cung cấp confidentiality, không tự đảm bảo authenticated encryption cho mọi cấu hình. dm-integrity và authenticated modes tồn tại nhưng có yêu cầu về format, compatibility, recovery và hiệu năng riêng. Nếu cần chống sửa đổi block, thiết kế và load-test như một kiến trúc storage riêng; đừng thêm option vào volume production hiện hữu mà chưa có migration/recovery plan.

12. Backup dữ liệu mã hóa

Encryption không cứu dữ liệu khỏi disk failure. Có hai hướng phổ biến:

• Block image: giữ dữ liệu ở dạng ciphertext nhưng sao chép cả khoảng trống, khó nén và clone cả volume key/header.
• Filesystem-level backup: hiệu quả và linh hoạt hơn, nhưng dữ liệu đã được giải mã khi đọc nên backup phải có lớp mã hóa, key và access policy độc lập.

Không phát tán một image LUKS mẫu cho cả fleet: các máy sẽ dùng chung volume key dù sau đó đổi passphrase. Hãy tạo LUKS volume mới trên từng máy và restore dữ liệu qua quy trình provisioning.

13. Monitoring và audit không làm lộ secret

cryptsetup status app_crypt
lsblk -f
dmsetup info /dev/mapper/app_crypt
journalctl -b --no-pager | grep -iE 'crypt|luks|dm-' 

Theo dõi boot unlock failure, thời gian mở khóa, mapped-device state, lỗi I/O, key rotation overdue, tuổi header backup và tuổi restore drill. Không thu thập passphrase, raw key, command line có secret hoặc trace nhạy cảm. Alert cần phân biệt volume cố ý đóng với volume đáng lẽ phải mở.

Checklist production

• Threat model nêu rõ data-at-rest, runtime và boot-chain risk.
• Device được nhận diện bằng by-id/UUID và có inventory owner.
• Tham số LUKS2/PBKDF dựa trên phiên bản, benchmark và policy hiện tại.
• Có ít nhất một recovery method độc lập, được test trước khi thu hồi key cũ.
• Rotation theo add → test → deploy → boot test → remove.
• Header backup được mã hóa, tách fault domain, kiểm soát phiên bản và checksum.
• Boot/initramfs failure mode và remote-console recovery đã được diễn tập.
• Swap, hibernate, crash dump, discard và auto-unlock có quyết định rõ ràng.
• Backup dữ liệu độc lập với header backup và có restore test.
• Monitoring không ghi secret nhưng phát hiện unlock, I/O và rotation failure.

Kết luận

LUKS2 và dm-crypt cung cấp nền tảng mã hóa block mạnh cho Linux, nhưng production safety nằm ở vòng đời khóa và khả năng phục hồi. Chọn default hiện đại, hiểu keyslot, bảo vệ header backup, kiểm chứng khóa mới trước khi thu hồi khóa cũ, thiết kế boot failure có lối thoát và luôn giữ backup dữ liệu độc lập. Mã hóa tốt biến một ổ đĩa bị lấy cắp thành dữ liệu vô nghĩa; vận hành tốt ngăn chính đội ngũ của bạn biến dữ liệu hợp lệ thành thứ không thể mở lại.