Kadang-kadang saya mencari-cari topik untuk ditulis, dan menyadari bahwa ada satu yang saya anggap telah saya bahas, tetapi, saat mencari, ternyata belum. Salah satu topik tersebut adalah booting terukur dan boot tepercaya—terkadang secara keliru disebut sebagai "boot aman". Ada prosedur khusus yang menggunakan istilah ini dengan huruf kapital (mis., Boot Aman), yang akan saya coba hindari untuk dibahas dalam artikel ini. Saya lebih tertarik pada proses generik—dan potensi kejatuhan yang besar—daripada mencoba masuk ke seluk beluk spesifik. Berikut ini adalah kutipan (yang banyak diedit) dari buku saya yang akan datang tentang kepercayaan dalam komputasi dan cloud untuk Wiley.
Lebih banyak sumber daya Linux
- Lembar contekan perintah Linux
- Lembar contekan perintah Linux tingkat lanjut
- Kursus online gratis:Ikhtisar Teknis RHEL
- Lembar contekan jaringan Linux
- Lembar contekan SELinux
- Lembar contekan perintah umum Linux
- Apa itu container Linux?
- Artikel Linux terbaru kami
Untuk memahami apa yang ingin dicapai dengan boot terukur dan boot tepercaya, lihat tumpukan virtualisasi Linux:komponen yang Anda jalankan jika Anda ingin menggunakan mesin virtual (VM) di mesin Linux. Deskripsi ini bisa dibilang terlalu disederhanakan, tetapi (seperti yang saya sebutkan di atas) saya tidak tertarik secara spesifik tetapi pada apa yang saya coba capai. Saya akan berkonsentrasi pada empat lapisan terbawah (pada tingkat abstraksi yang agak sederhana):CPU/mesin manajemen; BIOS/EFI; firmware; dan hypervisor, tetapi saya juga akan mempertimbangkan lapisan hanya di atas mesin CPU/manajemen, yang menempatkan Trusted Platform Module (TPM) dan beberapa instruksi tentang cara melakukan salah satu dari dua proses (boot terukur dan boot tepercaya ). Setelah sistem mulai boot, TPM dipicu dan mulai bekerja. Akar kepercayaan alternatif, seperti modul keamanan perangkat keras (HSM), mungkin juga digunakan, tetapi saya akan menggunakan TPM, contoh paling umum dalam konteks ini, dalam contoh saya.
Dalam kedua kasus (boot tepercaya dan boot terukur), aliran dasar dimulai dengan TPM melakukan pengukuran lapisan BIOS/EFI. Pengukuran ini melibatkan pemeriksaan instruksi biner yang akan dilakukan oleh lapisan ini dan membuat hash kriptografi dari gambar biner. Hash yang dihasilkan kemudian disimpan di salah satu dari beberapa "slot" Platform Configuration Register (PCR) di TPM. Ini dapat dianggap sebagai bagian dari memori yang dapat dibaca nanti - baik oleh TPM untuk tujuannya atau oleh entitas di luar TPM - tetapi tidak dapat diubah setelah ditulis. Potongan-potongan memori ini dilindungi integritasnya sejak pertama kali ditulis. Ini memberikan jaminan bahwa setelah nilai ditulis ke PCR oleh TPM, nilai tersebut dapat dianggap konstan selama masa pakai sistem hingga daya mati atau reboot.
Setelah mengukur lapisan BIOS/EFI, lapisan berikutnya (firmware) diukur. Dalam hal ini hash yang dihasilkan digabungkan dengan hash sebelumnya (yang disimpan di slot PCR) kemudian juga disimpan di slot PCR. Proses berlanjut sampai semua lapisan yang terlibat dalam proses telah diukur dan hasil hash telah disimpan. Ada (terkadang cukup rumit) proses untuk mengatur nilai TPM asli (saya telah melewatkan beberapa langkah tingkat rendah dalam proses untuk kesederhanaan) dan untuk mengizinkan (semoga diizinkan) perubahan pada lapisan untuk peningkatan atau patch keamanan , Misalnya. Proses "boot terukur" ini memungkinkan entitas untuk menanyakan TPM setelah proses selesai dan untuk memeriksa apakah nilai dalam slot PCR sesuai dengan nilai yang diharapkan, yang telah dihitung sebelumnya dengan versi "yang diketahui baik" dari berbagai lapisan—yaitu , versi yang telah diperiksa sebelumnya yang asal dan integritasnya telah ditetapkan.
Berbagai protokol ada untuk mengizinkan pihak eksternal ke sistem untuk memeriksa nilai (misalnya, melalui koneksi jaringan) yang dibuktikan kebenarannya oleh TPM:proses menerima dan memeriksa nilai tersebut dari sistem eksternal dikenal sebagai "pengesahan jarak jauh".
Proses ini—boot terukur—memungkinkan Anda untuk mengetahui apakah fondasi sistem Anda—lapisan terendah—adalah seperti yang Anda pikirkan. Tapi bagaimana jika mereka tidak? Boot terukur (tidak mengejutkan, mengingat namanya) mengukur tetapi tidak melakukan tindakan lain.
Alternatifnya, "boot tepercaya," melangkah lebih jauh. Ketika proses boot tepercaya dilakukan, proses tidak hanya mengukur setiap nilai tetapi juga melakukan pemeriksaan terhadap nilai baik yang diketahui (dan diharapkan!) pada saat yang bersamaan. Jika pemeriksaan gagal, maka proses akan berhenti, dan booting sistem akan gagal. Ini mungkin terdengar seperti pendekatan yang agak ekstrim untuk mengambil suatu sistem, tetapi kadang-kadang itu benar-benar tepat. Jika sistem yang dipertimbangkan mungkin telah disusupi—yang merupakan salah satu kemungkinan kesimpulan yang dapat Anda buat dari kegagalan proses boot tepercaya—lebih baik sistem tidak tersedia sama sekali daripada dijalankan berdasarkan ekspektasi yang salah.
Ini semua sangat baik jika saya pemilik sistem yang diukur, telah memeriksa semua berbagai komponen yang diukur (dan pengukuran), dan senang bahwa apa yang sedang di-boot adalah apa yang saya inginkan. Tetapi bagaimana jika saya menggunakan sistem di cloud, misalnya, atau sistem apa pun yang dimiliki dan dikelola oleh orang lain? Dalam hal ini, saya mempercayai penyedia cloud (atau pemilik/pengelola) dengan dua hal:
- Melakukan semua pengukuran dengan benar dan melaporkan hasil yang benar kepada saya
- Membangun sesuatu yang harus kupercaya sejak awal
Ini adalah masalah dengan nomenklatur "boot tepercaya" dan, lebih buruk lagi, "boot aman". Keduanya menyiratkan bahwa sifat objektif dan absolut dari suatu sistem telah ditetapkan—itu "tepercaya" atau "aman"—ketika ini jelas bukan masalahnya. Jelas, tidak adil untuk mengharapkan perancang proses semacam itu untuk menamainya setelah status kegagalan—"boot tidak tepercaya" atau "boot tidak aman"—tetapi, kecuali saya bisa sangat yakin bahwa saya memercayai pemilik sistem untuk melakukan langkah dua sepenuhnya dengan benar (dan demi kepentingan terbaik saya sebagai pengguna sistem, daripada mereka sebagai pemilik), maka saya tidak dapat membuat pernyataan yang lebih kuat.
Ada godaan besar untuk mengambil sistem yang telah melalui proses boot tepercaya dan melabelinya sebagai "sistem tepercaya" ketika yang terbaik pernyataan yang dapat Anda buat adalah bahwa lapisan tertentu yang diukur dalam proses boot yang terukur dan/atau tepercaya telah dinyatakan sebagai lapisan yang diharapkan oleh proses tersebut. Proses seperti itu sama sekali tidak menjelaskan tentang kesesuaian lapisan untuk memberikan jaminan perilaku atau tentang kebenaran (atau kesesuaian untuk memberikan jaminan perilaku) dari lapisan berikutnya di atas lapisan tersebut.
Penting untuk dicatat bahwa perancang TPM cukup jelas dengan apa yang ditegaskan dan bahwa penegasan tentang kepercayaan harus dibuat dengan hati-hati dan hemat. Sayangnya, bagaimanapun, kompleksitas sistem, tingkat pemahaman kepercayaan yang rendah secara umum, dan kompleksitas konteks dan kepercayaan transitif membuatnya sangat mudah bagi perancang dan pelaksana sistem untuk melakukan hal yang salah dan berasumsi bahwa sistem apa pun yang telah berhasil melakukan proses boot tepercaya dapat dianggap "tepercaya." Juga sangat penting untuk diingat bahwa TPM, sebagai akar kepercayaan perangkat keras, menawarkan salah satu mekanisme terbaik yang tersedia untuk membangun rantai kepercayaan dalam sistem yang mungkin Anda rancang atau implementasikan, dan saya berencana untuk segera menulis artikel tentangnya.
- Meskipun ini ternyata banyak lebih sulit untuk dilakukan daripada yang Anda harapkan!
Artikel ini awalnya diterbitkan di Alice, Eve, dan Bob dan dicetak ulang dengan izin penulis.