Disk Encryption

Permission dan sudo menjaga data dari user lain selama sistem berjalan — tetapi keduanya tidak berdaya saat disk itu sendiri berpindah tangan. Hard disk yang dicabut dari laptop dan dipasang di komputer lain langsung terbaca isinya, karena aturan permission hanya ditaati oleh Linux yang sedang hidup di atasnya. Enkripsi disk menutup celah ini: data disimpan sebagai ciphertext yang tak berarti tanpa kunci, dan hanya kembali terbaca setelah kunci diketik saat boot. Chapter ini membahas lapisan dm-crypt di dalam kernel, format LUKS beserta master key dan keyslot-nya, proses membuka kunci saat boot, serta skenario enkripsi yang bisa kita pilih.

Data dalam Tiga Keadaan #

Praktik keamanan membagi hidup data menjadi tiga keadaan, dan masing-masing punya penjaganya sendiri:

Enkripsi disk bicara soal baris terakhir. Selama mesin menyala dan partisi sudah dibuka, kernel-lah yang menyandianya secara transparan — aplikasi tidak melihat perbedaan apa pun. Perbedaan baru terasa saat disk diam: dicuri, dijual, atau dibaca dari sistem lain yang tidak merasa wajib menghormati permission Linux.

dm-crypt di Kernel, LUKS sebagai Formatnya #

dm-crypt adalah bagian kernel yang menerjemahkan setiap baca-tulis pada sebuah device virtual menjadi operasi dekripsi-enkripsi pada device fisik di belakangnya. Lapisan ini buta format — ia hanya menyandi dan membuka blok data. LUKS (Linux Unified Key Setup) adalah format yang bekerja di atasnya: standar penataan metadata dan kunci di awal partisi, sehingga partisi buatan Debian bisa dibuka oleh Fedora dan sebaliknya. Alat untuk semuanya adalah cryptsetup.

Bagian terpenting LUKS adalah dua kunci dengan peran berbeda. Master key dibuat acak saat partisi diformat, dan master key itulah yang mengenkripsi seluruh data. Passphrase yang kita ketik tidak pernah menyentuh data — passphrase hanya membuka salinan master key yang tersimpan terenkripsi di dalam header, pada wadah bernama keyslot. Susunan ini menjelaskan dua perilaku yang sering mengejutkan: mengganti passphrase tidak mengenkripsi ulang data (hanya keyslot yang ditulis ulang), dan satu partisi bisa dibuka beberapa passphrase berbeda. Kita buktikan perilaku kedua dengan peraga openssl:

printf 'master-key-tiruan-0123456789abcdef' > kunci-master
openssl enc -aes-256-cbc -pbkdf2 -pass pass:PASSWORD_BUDI -in kunci-master -out slot-budi
openssl enc -aes-256-cbc -pbkdf2 -pass pass:PASSWORD_OPS -in kunci-master -out slot-ops
openssl enc -d -aes-256-cbc -pbkdf2 -pass pass:PASSWORD_OPS -in slot-ops | cmp - kunci-master && echo "slot tim-ops membuka master key yang sama"
openssl enc -d -aes-256-cbc -pbkdf2 -pass pass:PASSWORD_BUDI -in slot-budi | cmp - kunci-master && echo "slot budi membuka master key yang sama"

Output yang Dihasilkan:

slot tim-ops membuka master key yang sama
slot budi membuka master key yang sama

Mari kita bedah peraga di atas:

1. Baris 1 (printf ... > kunci-master): membuat master key tiruan. Pada LUKS asli, master key dibuat acak sepanjang 256 bit oleh kernel — panjang yang membuat brute force terhadap data tidak realistis.
2. Baris 2-3 (openssl enc ... -out slot-...): mengenkripsi file kunci-master dengan dua passphrase berbeda, menghasilkan dua “keyslot” yang isinya sama sekali berbeda byte-per-byte meski kunci masternya identik.
3. Baris 4-5 (openssl enc -d ... | cmp - kunci-master): mendekripsi tiap slot dengan passphrase pembuatnya lalu membandingkan hasilnya dengan kunci-master. Kedua baris tercetak — dua passphrase berbeda membuka master key yang sama. Pada LUKS sungguhan, ini setara cryptsetup luksAddKey: satu keyslot untuk kita, satu cadangan untuk tim.

Saat Disk Jatuh ke Tangan Pencuri #

Kini kita lihat wajah data at rest dari sudut pandang pencuri. Karena cryptsetup membutuhkan partisi fisik, kita peragakan prinsipnya pada dua file: satu “disk mentah” berisi data polos, satu hasil enkripsi menyeluruh:

printf 'NAMA=budi\nREKENING=123-456-789\nPIN=0812\n' > disk-mentah.img
openssl enc -aes-256-cbc -pbkdf2 -pass pass:CONTOH_PASSWORD_KUAT -in disk-mentah.img -out disk-terenkripsi.img
echo '== teks yang terbaca dari disk mentah =='
strings disk-mentah.img
echo '== delapan byte pertama disk terenkripsi =='
head -c 8 disk-terenkripsi.img
echo
echo '== pola data pribadi yang masih terbaca =='
for f in disk-mentah.img disk-terenkripsi.img; do
  printf '%s: %d baris\n' "$f" "$(strings "$f" | grep -c 'NAMA\|REKENING\|PIN')"
done

Output yang Dihasilkan:

== teks yang terbaca dari disk mentah ==
NAMA=budi
REKENING=123-456-789
PIN=0812
== delapan byte pertama disk terenkripsi ==
Salted__
== pola data pribadi yang masih terbaca ==
disk-mentah.img: 3 baris
disk-terenkripsi.img: 0 baris

Mari kita bedah blok di atas:

1. Baris 1-2: disk-mentah.img diisi data pelanggan polos, lalu disalin dalam keadaan terenkripsi ke disk-terenkripsi.img dengan AES-256-CBC — cipher yang sama dipakai mode bawaan LUKS.
2. Baris 3-4 (strings disk-mentah.img): strings menyaring urutan karakter terbaca dari isi file. Pada disk mentah, seluruh data muncul polos — persis yang dilihat pencuri yang memasang disk kita di komputernya.
3. Baris 5-7 (head -c 8 ...): mengambil delapan byte pertama disk terenkripsi. Yang muncul hanyalah Salted__ — penanda kecil milik openssl bahwa sesudahnya ada salt; sisanya byte acak, dan penghitungan berikut membuktikannya.
4. Baris 8-11 (for f in ...): menghitung pola data pribadi yang masih terbaca di tiap file. Disk mentah menjelaskan tiga baris, disk terenkripsi nihil.

Fakta Salted__ yang tetap terbaca itu sendiri pelajaran: header bukan data, ia metadata. LUKS memakai prinsip yang sama — header di megabyte pertama partisi memang terbaca siapa pun, tetapi isinya hanya metadata dan keyslot terenkripsi, bukan satu byte data pun.

Membuka Kunci Saat Boot: /boot, initramfs, dan swap #

Partisi root terenkripsi menimbulkan teka-teki ayam dan telur: kalau kernel dan program enkripsi ada di dalam partisi yang terkunci, siapa yang membukanya? GRUB memuat kernel dan initramfs dari partisi /boot yang umumnya sengaja dibiarkan tidak terenkripsi. initramfs — sistem akar mini di dalam RAM — membawa modul dm-crypt dan cryptsetup; ia yang menanyai passphrase, membuka partisi root, lalu menyerahkan kendali. Setelah terbuka, partisi muncul sebagai device virtual /dev/mapper/nama, dan itulah yang di-mount. File /etc/crypttab mencatat pasangan nama dan UUID partisi yang wajib terbuka setiap boot.

Karena cryptsetup membutuhkan akses partisi fisik, berikut contoh tampilan sesi pada disk sungguhan:

$ sudo cryptsetup luksFormat /dev/sdb1

WARNING!
========
This will overwrite data on /dev/sdb1 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sdb1:
Verify passphrase:

$ sudo cryptsetup luksOpen /dev/sdb1 data-rahasia
Enter passphrase for /dev/sdb1:

$ ls -1 /dev/mapper
control
data-rahasia

luksFormat menulis header dan master key baru sambil menuntut konfirmasi YES huruf kapital — penghapusan total tanpa undo. luksOpen membuka partisi dan membuat mapping data-rahasia. Selanjutnya mkfs.ext4 /dev/mapper/data-rahasia dijalankan sekali untuk membangun filesystem, lalu didaftarkan ke /etc/fstab seperti partisi biasa.

Satu kejujuran terakhir: /boot yang polos berarti siapa pun yang sempat memegang mesin secara fisik bisa mengganti initramfs agar mencuri passphrase kita saat boot berikutnya — serangan klasik bernama evil maid. Mitigasi nyatanya adalah TPM dan Secure Boot yang memverifikasi rantai boot.

Memilih Skenario Enkripsi #

Lapisan yang sama bisa dipasang pada cakupan berbeda, dan cakupan menentukan apa saja yang terlindungi:

Cakupan sempit menawarkan pemulihan cepat — server dengan OS polos bisa dipasang ulang dalam menit sementara partisi data dibuka dengan keyfile. Cakupan penuh menawarkan ketenangan: tidak ada file yang tertinggal polos, termasuk log di /var/log yang sering menyimpan kejutan.

Enkripsi memperkecil satu risiko besar menjadi satu kunci kecil yang harus dijaga — tetapi kunci bekerja diam-diam dan tidak melihat siapa yang mengubah /etc/passwd tadi malam. Untuk itu kita butuh mata yang mencatat segala kejadian di dalam kernel: pekerjaan auditd pada Chapter Audit Logs .

Referensi lanjut: cryptsetup(8) untuk referensi seluruh subperintahnya, wiki Arch Linux tentang dm-crypt untuk panduan penerapan per skenario, serta crypttab(5) untuk pembukaan otomatis saat boot.