Panduan Pembuatan dan Manajemen Kunci Boot Aman Windows

Dokumen ini membantu memandu OEM dan ODM dalam pembuatan dan pengelolaan kunci dan sertifikat Boot Aman di lingkungan manufaktur. Ini membahas pertanyaan yang terkait dengan pembuatan, penyimpanan, dan pengambilan Kunci Platform (PK), kunci pembaruan firmware yang aman, dan Kunci Pertukaran Kunci (KEK) pihak ketiga.

Catatan

OEM perangkat, perusahaan, dan pelanggan dapat menemukan biner PK, KEK, DB, dan DBX yang direkomendasikan Microsoft di repositori sumber terbuka Boot Aman Microsoft. Biner diformat ke format EDKII yang diharapkan untuk dengan mudah diintegrasikan ke dalam firmware.

Catatan

Microsoft Corporation KEK CA 2011 diatur untuk kedaluwarsa pada tahun 2026, dan semua OEM harus membuat, menandatangani, dan mengirimkan pembaruan untuk Microsoft Corporation KEK CA 2023 baru ke Microsoft. Ini akan memungkinkan Microsoft memperbarui perangkat di pasar dengan MICROSOFT KEK CA baru, memungkinkan sistem untuk terus menerima pembaruan DB dan DBX setelah 2026. Untuk petunjuk dan jaminan pengujian, silakan kunjungi https://aka.ms/KEKUpdatePackage

Persyaratan Windows untuk UEFI dan Boot Aman dapat ditemukan di Persyaratan Sertifikasi Perangkat Keras Windows. Makalah ini tidak memperkenalkan persyaratan baru atau mewakili program Windows resmi. Ini dimaksudkan sebagai panduan di luar persyaratan sertifikasi, untuk membantu membangun proses yang efisien dan aman untuk membuat dan mengelola Kunci Boot Aman. Ini penting karena Boot Aman UEFI didasarkan pada penggunaan Infrastruktur Kunci Umum untuk mengautentikasi kode sebelum diizinkan untuk dijalankan.

Pembaca diharapkan mengetahui dasar-dasar UEFI, pemahaman dasar tentang Boot Aman (Bab 27 spesifikasi UEFI), dan model keamanan PKI.

Persyaratan, pengujian, dan alat yang memvalidasi Boot Aman di Windows tersedia hari ini melalui Windows Hardware Certification Kit (HCK). Namun, sumber daya HCK ini tidak mengatasi pembuatan dan pengelolaan kunci untuk penyebaran Windows. Makalah ini membahas manajemen kunci sebagai sumber daya untuk membantu memandu mitra melalui penyebaran kunci yang digunakan oleh firmware. Ini tidak dimaksudkan sebagai panduan preskriptif dan tidak termasuk persyaratan baru.

Pada halaman ini:

• 1. Boot Aman, Windows, dan Manajemen Kunci berisi informasi tentang keamanan boot dan arsitektur PKI karena berlaku untuk Windows dan Boot Aman.
• 2. Solusi Manajemen Kunci dimaksudkan untuk membantu mitra merancang manajemen kunci dan solusi desain yang sesuai dengan kebutuhan mereka.
• 3. Ringkasan dan Sumber Daya mencakup lampiran, daftar periksa, API, dan referensi lainnya.

Dokumen ini berfungsi sebagai titik awal dalam mengembangkan PC siap pelanggan, alat penyebaran pabrik, dan praktik terbaik keamanan utama.

1. Boot Aman, Windows dan Manajemen Kunci

Spesifikasi UEFI (Unified Extensible Firmware Interface) mendefinisikan proses autentikasi eksekusi firmware yang disebut Boot Aman. Sebagai standar industri, Boot Aman mendefinisikan bagaimana firmware platform mengelola sertifikat, mengautentikasi firmware, dan bagaimana antarmuka sistem operasi dengan proses ini.

Boot Aman didasarkan pada proses Infrastruktur Kunci Umum (PKI) untuk mengautentikasi modul sebelum diizinkan untuk dijalankan. Modul ini dapat mencakup driver firmware, OPSI ROM, driver UEFI pada disk, aplikasi UEFI, atau boot loader UEFI. Melalui autentikasi gambar sebelum eksekusi, Boot Aman mengurangi risiko serangan malware pra-boot seperti rootkit. Microsoft mengandalkan Boot Aman UEFI di Windows 8 ke atas sebagai bagian dari arsitektur keamanan Boot Tepercayanya untuk meningkatkan keamanan platform bagi pelanggan kami. Boot Aman diperlukan untuk PC klien Windows 8 ke atas, dan untuk Windows Server 2016 seperti yang didefinisikan dalam Persyaratan Kompatibilitas Perangkat Keras Windows.

Proses Boot Aman berfungsi sebagai berikut dan seperti yang ditunjukkan pada Gambar 1:

1. Komponen Boot Firmware: Firmware memverifikasi pemuat OS tepercaya (Windows atau sistem operasi tepercaya lainnya.)
2. Komponen boot Windows: BootMgr, WinLoad, Windows Kernel Startup. Komponen boot Windows memverifikasi tanda tangan pada setiap komponen. Komponen yang tidak tepercaya tidak akan dimuat dan sebaliknya akan memicu remediasi Boot Aman.
   • Inisialisasi Perangkat Lunak Antivirus dan Antimalware: Perangkat lunak ini diperiksa untuk tanda tangan khusus yang dikeluarkan oleh Microsoft yang memverifikasi bahwa ini adalah driver penting boot tepercaya, dan akan diluncurkan di awal proses boot.
   • Inisialisasi Boot Critical Driver: Tanda tangan pada semua driver Boot-critical diperiksa sebagai bagian dari verifikasi Boot Aman di WinLoad.
3. Inisialisasi OS Tambahan
4. Layar Masuk Windows

Gambar 1: Arsitektur Boot Tepercaya Windows

Implementasi Boot Aman UEFI adalah bagian dari Arsitektur Boot Tepercaya Microsoft, yang diperkenalkan di Windows 8.1. Tren yang berkembang dalam evolusi eksploitasi malware menargetkan jalur boot sebagai vektor serangan pilihan. Kelas serangan ini sulit dijaga, karena produk antimalware dapat dinonaktifkan oleh perangkat lunak berbahaya yang mencegah mereka memuat sepenuhnya. Dengan arsitektur Windows Trusted Boot dan pembentukan akar kepercayaannya dengan Boot Aman, pelanggan dilindungi dari kode berbahaya yang dijalankan di jalur boot dengan memastikan bahwa hanya kode "baik" bersertifikat yang ditandatangani dan dapat dijalankan oleh pemuat boot sebelum sistem operasi itu sendiri dimuat.

1.1 Infrastruktur Kunci Umum (PKI) dan Boot Aman

PKI menetapkan keaslian dan kepercayaan pada sistem. Boot Aman memanfaatkan PKI untuk dua tujuan tingkat tinggi:

1. Selama boot untuk menentukan apakah modul boot awal dipercaya untuk eksekusi.
2. Untuk mengautentikasi permintaan ke permintaan layanan termasuk modifikasi database Boot Aman dan pembaruan firmware platform.

PKI terdiri dari:

• Otoritas sertifikat (CA) yang mengeluarkan sertifikat digital.
• Otoritas pendaftaran yang memverifikasi identitas pengguna yang meminta sertifikat dari CA.
• Direktori pusat untuk menyimpan dan mengindeks kunci.
• Sistem manajemen sertifikat.

1.2 Kriptografi Kunci Umum

Kriptografi kunci publik menggunakan sepasang kunci kriptografi terkait matematis, yang dikenal sebagai kunci publik dan privat. Jika Anda mengetahui salah satu kunci, Anda tidak dapat dengan mudah menghitung apa yang lain. Jika satu kunci digunakan untuk mengenkripsi informasi, maka hanya kunci yang sesuai yang dapat mendekripsi informasi tersebut. Untuk Boot Aman, kunci privat digunakan untuk menandatangani kode secara digital dan kunci publik digunakan untuk memverifikasi tanda tangan pada kode tersebut untuk membuktikan keasliannya. Jika kunci privat disusupi, maka sistem dengan kunci publik yang sesuai tidak lagi aman. Hal ini dapat menyebabkan serangan boot kit dan akan merusak reputasi entitas yang bertanggung jawab untuk memastikan keamanan kunci privat.

Dalam sistem kunci umum Boot Aman, Anda memiliki hal berikut:

• 1.2.1 Enkripsi RSA 2048

  RSA-2048 adalah algoritma kriptografi asimetris. Ruang yang diperlukan untuk menyimpan modulus RSA-2048 dalam bentuk mentah adalah 2048 bit.

• 1.2.2 Sertifikat yang ditandatangani sendiri

  Sertifikat yang ditandatangani oleh kunci privat yang cocok dengan kunci umum sertifikat dikenal sebagai sertifikat yang ditandatangani sendiri. Sertifikat otoritas sertifikasi akar (CA) termasuk dalam kategori ini.

• 1.2.3 Otoritas Sertifikasi

  Otoritas sertifikasi (CA) mengeluarkan sertifikat yang ditandatangani yang menandakan identitas subjek sertifikat dan mengikat identitas tersebut ke kunci publik yang terkandung dalam sertifikat. CA menandatangani sertifikat dengan menggunakan kunci privatnya. Ini mengeluarkan kunci publik yang sesuai untuk semua pihak yang tertarik dalam sertifikat OS akar yang ditandatangani sendiri.

  Dalam Boot Aman, Otoritas Sertifikasi (CA) menyertakan OEM (atau delegasinya) dan Microsoft. CA menghasilkan pasangan kunci yang membentuk akar kepercayaan dan kemudian menggunakan kunci privat untuk menandatangani operasi yang sah seperti modul EFI boot awal yang diizinkan dan permintaan layanan firmware. Kunci publik yang sesuai dikirimkan disematkan ke dalam firmware UEFI pada PC berkemampuan Boot Aman dan digunakan untuk memverifikasi operasi ini.

  (Informasi lebih lanjut tentang penggunaan CA dan pertukaran kunci tersedia di internet yang berkaitan dengan model Boot Aman.)

• 1.2.4 Kunci Umum

  Kunci Platform publik dikirim di PC dan dapat diakses atau "publik". Dalam dokumen ini kita akan menggunakan akhiran "pub" untuk menunjukkan kunci publik. Misalnya, PKpub menunjukkan setengah dari PK publik.

• 1.2.5 Kunci Privat

  Agar PKI dapat bekerja kunci privat perlu dikelola dengan aman. Ini harus dapat diakses oleh beberapa individu yang sangat tepercaya di organisasi dan terletak di lokasi yang aman secara fisik dengan pembatasan kebijakan akses yang kuat. Dalam dokumen ini kita akan menggunakan akhiran "priv" untuk menunjukkan kunci privat. Misalnya, PKpriv menunjukkan setengah privat dari PK.

• 1.2.6 Sertifikat

  Penggunaan utama untuk sertifikat digital adalah untuk memverifikasi asal data yang ditandatangani, seperti biner dll. Penggunaan umum sertifikat adalah untuk keamanan pesan internet menggunakan Keamanan Lapisan Transportasi (TLS) atau Secure Sockets Layer (SSL). Memverifikasi data yang ditandatangani dengan sertifikat memungkinkan penerima mengetahui asal data dan apakah data tersebut telah diubah saat transit.

  Sertifikat digital secara umum berisi, pada tingkat tinggi, nama khusus (DN), kunci publik, dan tanda tangan. DN mengidentifikasi entitas -- perusahaan, misalnya -- yang menyimpan kunci privat yang cocok dengan kunci umum sertifikat. Menandatangani sertifikat dengan kunci privat dan menempatkan tanda tangan dalam sertifikat mengikat kunci privat ke kunci publik.

  Sertifikat dapat berisi beberapa jenis data lainnya. Misalnya, sertifikat X.509 menyertakan format sertifikat, nomor seri sertifikat, algoritma yang digunakan untuk menandatangani sertifikat, nama CA yang menerbitkan sertifikat, nama dan kunci umum entitas yang meminta sertifikat, dan tanda tangan CA.

• 1.2.7 Sertifikat rantai

  Dari: Rantai sertifikat:

  

  Gambar 2: Rantai tiga sertifikat

  Sertifikat pengguna sering ditandatangani oleh kunci privat yang berbeda, seperti kunci privat CA. Ini merupakan rantai dua sertifikat. Memverifikasi bahwa sertifikat pengguna asli melibatkan verifikasi tanda tangannya, yang memerlukan kunci umum CA, dari sertifikatnya. Tetapi sebelum kunci publik CA dapat digunakan, sertifikat CA yang disertakan perlu diverifikasi. Karena sertifikat CA ditandatangani sendiri, kunci publik CA digunakan untuk memverifikasi sertifikat.

  Sertifikat pengguna tidak perlu ditandatangani oleh kunci privat OS akar. Ini dapat ditandatangani oleh kunci privat perantara yang sertifikatnya ditandatangani oleh kunci privat CA. Ini adalah instans rantai tiga sertifikat: sertifikat pengguna, sertifikat perantara, dan sertifikat CA. Tetapi lebih dari satu perantara dapat menjadi bagian dari rantai, sehingga rantai sertifikat dapat memiliki panjang apa pun.

1.3 Persyaratan PKI Boot Aman

Akar kepercayaan yang ditentukan UEFI terdiri dari Kunci Platform dan kunci apa pun yang disertakan OEM atau ODM dalam inti firmware. Keamanan pra-UEFI dan akar kepercayaan tidak ditangani oleh proses Boot Aman UEFI, tetapi sebaliknya oleh National Institute of Standards and Technology (NIST), dan publikasi Trusted Computing Group (TCG) yang dirujuk dalam makalah ini.

• 1.3.1 Persyaratan Boot Aman

  Anda harus mempertimbangkan parameter berikut untuk menerapkan Boot Aman:

  • Persyaratan pelanggan
  • Persyaratan Kompatibilitas Perangkat Keras Windows
  • Persyaratan pembuatan dan manajemen utama.

  Anda perlu memilih perangkat keras untuk manajemen kunci Boot Aman seperti Modul Keamanan Perangkat Keras (HSM), pertimbangkan persyaratan khusus pada PC untuk dikirim ke pemerintah dan lembaga lain dan akhirnya proses pembuatan, pengisian, dan pengelolaan siklus hidup berbagai kunci Boot Aman.

• 1.3.2 Kunci terkait Boot Aman

  Kunci yang digunakan untuk Boot Aman ada di bawah ini:

  

  Gambar 3: Kunci yang terkait dengan Boot Aman

  Gambar 3 di atas mewakili tanda tangan dan kunci di PC dengan Boot Aman. Platform ini diamankan melalui kunci platform yang diinstal OEM di firmware selama manufaktur. Kunci lain digunakan oleh Boot Aman untuk melindungi akses ke database yang menyimpan kunci untuk mengizinkan atau melarang eksekusi firmware.

  Database resmi (db) berisi kunci publik dan sertifikat yang mewakili komponen firmware tepercaya dan pemuat sistem operasi. Database tanda tangan terlarang (dbx) berisi hash komponen berbahaya dan rentan serta kunci dan sertifikat yang disusupi dan memblokir eksekusi komponen berbahaya tersebut. Kekuatan kebijakan ini didasarkan pada penandatanganan firmware menggunakan Authenticode dan Public Key Infrastructure (PKI). PKI adalah proses yang mapan untuk membuat, mengelola, dan mencabut sertifikat yang membangun kepercayaan selama pertukaran informasi. PKI adalah inti dari model keamanan untuk Boot Aman.

  Di bawah ini adalah detail selengkapnya tentang kunci ini.

• 1.3.3 Kunci Platform (PK)

  Sesuai bagian 27.5.1 dari UEFI 2.3.1 Errata C, kunci platform membangun hubungan kepercayaan antara pemilik platform dan firmware platform. Pemilik platform mendaftarkan setengah dari kunci publik (PKpub) ke dalam firmware platform seperti yang ditentukan dalam Bagian 7.2.1 dari UEFI 2.3.1 Errata C. Langkah ini memindahkan platform ke mode pengguna dari mode penyiapan. Microsoft merekomendasikan agar Kunci Platform berjenis EFI_CERT_X509_GUID dengan algoritma kunci publik RSA, panjang kunci publik 2048 bit, dan algoritma tanda tangan sha256RSA. Pemilik platform dapat menggunakan jenis EFI_CERT_RSA2048_GUID jika ruang penyimpanan menjadi perhatian. Kunci publik digunakan untuk memeriksa tanda tangan seperti yang dijelaskan sebelumnya dalam dokumen ini. Pemilik platform nantinya dapat menggunakan setengah privat dari kunci (PKpriv):

  • Untuk mengubah kepemilikan platform, Anda harus memasukkan firmware ke dalam mode penyiapan yang ditentukan UEFI yang menonaktifkan Boot Aman. Kembali ke mode penyiapan hanya jika ada kebutuhan untuk melakukan ini selama manufaktur.
  • Untuk perangkat desktop dan server, OEM dapat mengelola PK dan PKI yang diperlukan yang terkait dengannya, atau memilih untuk menggunakan PK yang dikelola Microsoft untuk OEM. PK yang dikelola Microsoft dilindungi oleh Microsoft HSM dan dikelola sebagai bagian dari praktik terbaik PKI. Ini adalah PK pilihan untuk ekosistem Windows.

  1.3.3.1 Untuk mendaftarkan atau memperbarui Kunci Pertukaran Kunci (KEK) Mendaftarkan Kunci Platform

  Pemilik platform mendaftarkan setengah publik Kunci Platform (PKpub) dengan memanggil UEFI Boot Service SetVariable() seperti yang ditentukan dalam Bagian 7.2.1 dari UEFI Spec 2.3.1 errata C, dan mengatur ulang platform. Jika platform dalam mode penyiapan, maka PKpub baru harus ditandatangani dengan mitra PKpriv-nya. Jika platform dalam mode pengguna, maka PKpub baru harus ditandatangani dengan PKpriv saat ini. Jika PK berjenis EFI_CERT_X509_GUID, maka ini harus ditandatangani oleh PKpriv segera, bukan kunci privat dari sertifikat apa pun yang dikeluarkan di bawah PK.

  1.3.3.2 Menghapus Kunci Platform

  Pemilik platform menghapus bagian publik dari Platform Key (PKpub) dengan memanggil UEFI Boot Ser¬vice SetVariable() dengan ukuran variabel 0 dan mengatur ulang platform. Jika platform dalam mode penyiapan, maka variabel kosong tidak perlu diautentikasi. Jika platform dalam mode pengguna, maka variabel kosong harus ditandatangani dengan PKpriv saat ini; lihat Bagian 7.2 (Layanan Variabel) di bawah spesifikasi UEFI 2.3.1 Errata C untuk detailnya. Sangat disarankan agar PKpriv produksi tidak pernah digunakan untuk menandatangani paket untuk mengatur ulang platform karena ini memungkinkan Boot Aman dinonaktifkan secara terprogram. Ini terutama merupakan skenario pengujian pra-produksi.

  Kunci platform juga dapat dibersihkan menggunakan metode khusus platform yang aman. Dalam hal ini, Mode Penyiapan variabel global juga harus diperbarui ke 1.

  

  Gambar 4: Diagram Status Kunci Platform

  1.3.3.3 Generasi PK

  Sesuai rekomendasi UEFI, kunci publik harus disimpan dalam penyimpanan non-volatil yang tahan terhadap perubahan dan penghapusan pada PC. Kunci Privat tetap aman di Mitra atau di Kantor Keamanan OEM dan hanya kunci umum yang dimuat ke platform. Ada detail selengkapnya di bawah bagian 2.2.1 dan 2.3.

  Microsoft menyediakan PK bagi OEM untuk menghilangkan tanggung jawab memelihara dan mengamankan sertifikat PK. PK dilindungi oleh Microsoft HSM dan dikelola sebagai bagian dari operasi Microsoft PKI kami.

  Jumlah PK yang dihasilkan adalah atas kebijakan pemilik Platform (OEM). Kunci-kunci ini bisa menjadi:

  1. Satu per PC. Memiliki satu kunci unik untuk setiap perangkat. Ini mungkin diperlukan untuk lembaga pemerintah, lembaga keuangan, atau pelanggan server lain dengan kebutuhan keamanan tinggi. Ini mungkin memerlukan penyimpanan tambahan dan daya pemrosesan kripto untuk menghasilkan kunci privat dan publik untuk sejumlah besar PC. Ini menambahkan kompleksitas perangkat pemetaan dengan PK yang sesuai saat mendorong pembaruan firmware ke perangkat di masa mendatang. Ada beberapa solusi HSM berbeda yang tersedia untuk mengelola sejumlah besar kunci berdasarkan vendor HSM. Untuk informasi selengkapnya, lihat Pembuatan Kunci Boot Aman Menggunakan HSM.

  2. Satu per model. Memiliki satu kunci per model PC. Tradeoff di sini adalah bahwa jika kunci disusupi semua mesin dalam model yang sama akan rentan. Ini direkomendasikan oleh Microsoft untuk PC desktop.

  3. Satu per lini produk. Jika kunci disusupi, seluruh lini produk akan rentan.

  4. Satu per OEM. Meskipun ini mungkin yang paling sederhana untuk diatur, jika kunci disusupi, setiap PC yang Anda buat akan rentan. Untuk mempercepat operasi di lantai pabrik, PK dan kemungkinan kunci lainnya dapat dibuat sebelumnya dan disimpan di lokasi yang aman. Ini nantinya dapat diambil dan digunakan di baris perakitan. Bab 2 dan 3 memiliki detail lebih lanjut.

  1.3.3.4 Memasukkan ulang PK

  Ini mungkin diperlukan jika PK disusupi atau sebagai persyaratan oleh pelanggan yang karena alasan keamanan dapat memutuskan untuk mendaftarkan PK mereka sendiri.

  Kunci ulang dapat dilakukan baik untuk model atau PC berdasarkan metode apa yang dipilih untuk membuat PK. Semua PC yang lebih baru akan ditandatangani dengan PK yang baru dibuat.

  Memperbarui PK pada PC produksi akan memerlukan pembaruan variabel yang ditandatangani dengan PK yang ada yang menggantikan PK atau paket pembaruan firmware. OEM juga dapat membuat paket SetVariable() dan mendistribusikannya dengan aplikasi sederhana seperti PowerShell yang hanya mengubah PK. Paket pembaruan firmware akan ditandatangani oleh kunci pembaruan firmware yang aman dan diverifikasi oleh firmware. Jika melakukan pembaruan firmware untuk memperbarui PK, perawatan harus dilakukan untuk memastikan KEK, db, dan dbx dipertahankan.

  Pada semua PC, disarankan untuk tidak menggunakan PK sebagai kunci pembaruan firmware yang aman. Jika PKpriv disusupi maka begitu juga kunci pembaruan firmware yang aman (karena keduanya sama). Dalam hal ini pembaruan untuk mendaftarkan PKpub baru mungkin tidak dimungkinkan karena proses pembaruan juga telah disusupi.

  Pada PC SOC, ada alasan lain untuk tidak menggunakan PK sebagai kunci pembaruan firmware yang aman. Ini karena kunci pembaruan firmware yang aman dibakar secara permanen ke dalam sekering pada PC yang memenuhi persyaratan Sertifikasi Perangkat Keras Windows.

• 1.3.4 Kunci Pertukaran Kunci (KEK) Kunci kunci membangun hubungan kepercayaan antara sistem operasi dan firmware platform. Setiap sistem operasi (dan berpotensi, setiap aplikasi pihak ke-3 yang perlu berkomunikasi dengan firmware platform) mendaftarkan kunci umum (KEKpub) ke dalam firmware platform.

  1.3.4.1 Mendaftarkan Kunci Pertukaran Kunci

  Kunci pertukaran kunci disimpan dalam database tanda tangan seperti yang dijelaskan dalam Database Tanda Tangan 1.4 (Db dan Dbx)). Database tanda tangan disimpan sebagai variabel UEFI yang diautentikasi.

  Pemilik platform mendaftarkan kunci pertukaran kunci dengan memanggil SetVariable() seperti yang ditentukan dalam Bagian 7.2 (Layanan Variabel) berdasarkan spesifikasi UEFI 2.3.1 Errata C. dengan EFI_VARIABLE_APPEND_WRITE set atribut dan parameter Data yang berisi kunci baru, atau dengan membaca database menggunakan GetVariable(), menambahkan kunci pertukaran kunci baru ke kunci yang ada lalu menulis database menggunakan SetVariable()seperti yang ditentukan dalam Bagian 7.2(Layanan Variabel) di bawah spesifikasi UEFI 2.3.1 Errata C tanpa EFI_VARIABLE_APPEND_WRITE set atribut.

  Jika platform dalam mode penyiapan, variabel database tanda tangan tidak perlu ditandatangani tetapi parameter untuk panggilan SetVariable() masih harus disiapkan seperti yang ditentukan untuk variabel terautentikasi di Bagian 7.2.1. Jika platform dalam mode pengguna, database tanda tangan harus ditandatangani dengan PKpriv saat ini

  1.3.4.2 Menghapus KEK

  Dimungkinkan untuk "menghapus" (menghapus) KEK. Perhatikan bahwa jika PK tidak diinstal pada platform, permintaan "clear" tidak diperlukan untuk ditandatangani. Jika ditandatangani, maka untuk menghapus KEK memerlukan paket yang ditandatangani PK, dan untuk menghapus db atau dbx memerlukan paket yang ditandatangani oleh entitas apa pun yang ada di KEK.

  1.3.4.3 Microsoft KEK

  Sertifikat Microsoft KEK berikut diperlukan untuk memungkinkan pencabutan gambar rusak dengan memperbarui dbx dan berpotensi memperbarui db untuk mempersiapkan gambar Windows yang ditandatangani di masa depan.

1. Microsoft Corporation KEK 2K CA 2023

   • Hash sertifikasi SHA-1: 459AB6FB5E284D272D5E3E6ABC8ED663829D632B.
   • GUID SignatureOwner: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
   • Microsoft akan memberikan sertifikat kepada mitra dan dapat ditambahkan baik sebagai EFI_CERT_X509_GUID tanda tangan jenis atau EFI_CERT_RSA2048_GUID .
   • Sertifikat Microsoft KEK dapat diunduh dari: https://go.microsoft.com/fwlink/?linkid=2239775.

1.3.4.4 KEKDefault Vendor platform harus menyediakan sekumpulan Kunci Pertukaran Kunci default dalam variabel KEKDefault. Silakan referensi spesifikasi UEFI bagian 27.3.3 untuk informasi lebih lanjut.

1.3.4.5 OEM/KEK pihak ke-3 - menambahkan beberapa KEK

Pelanggan dan Pemilik Platform tidak perlu memiliki KEK sendiri. Pada PC RT non-Windows, OEM mungkin memiliki KEK tambahan untuk memungkinkan OEM tambahan atau kontrol pihak ke-3 tepercaya dari db dan dbx.

• 1.3.5 Kuncipembaruan firmware Boot Aman Kunci pembaruan firmware Aman digunakan untuk menandatangani firmware saat perlu diperbarui. Kunci ini harus memiliki kekuatan kunci minimum RSA-2048. Semua pembaruan firmware harus ditandatangani dengan aman oleh OEM, delegasi tepercaya mereka seperti ODM atau IBV (Vendor BIOS Independen), atau oleh layanan penandatanganan yang aman.

  Sesuai publikasi NIST 800-147 Field Firmware Update harus mendukung semua elemen pedoman:

  Setiap pembaruan ke penyimpanan flash firmware harus ditandatangani oleh pembuat.

  Firmware harus memeriksa tanda tangan pembaruan.

• 1.3.6 Pembuatan kunci untuk Pembaruan Firmware Aman

  Kunci yang sama akan digunakan untuk menandatangani semua pembaruan firmware karena setengah publik akan berada di PC. Anda juga dapat menandatangani pembaruan firmware dengan kunci yang berantai ke kunci pembaruan Firmware Aman.

  Mungkin ada satu kunci per PC seperti PK atau satu per model atau satu per lini produk. Jika ada satu kunci per PC yang berarti bahwa jutaan paket pembaruan unik perlu dihasilkan. Harap pertimbangkan berdasarkan ketersediaan sumber daya metode apa yang akan berfungsi untuk Anda. Memiliki kunci per model atau lini produk adalah kompromi yang baik.

  Kunci publik Secure Firmware Update (atau hashnya untuk menghemat ruang) akan disimpan di beberapa penyimpanan yang dilindungi pada platform - umumnya dilindungi flash (PC) atau sekering yang dapat diprogram satu kali (SOC).

  Jika hanya hash kunci ini yang disimpan (untuk menghemat ruang), pembaruan firmware akan menyertakan kunci, dan tahap pertama proses pembaruan akan memverifikasi bahwa kunci publik dalam pembaruan cocok dengan hash yang disimpan di platform.

  Kapsul adalah sarana di mana OS dapat meneruskan data ke lingkungan UEFI di seluruh boot ulang. Windows memanggil UEFI UpdateCapsule() untuk memberikan pembaruan firmware sistem dan PC. Pada waktu boot sebelum memanggil ExitBootServices(), Windows akan meneruskan pembaruan firmware baru yang ditemukan di Windows Driver Store ke UpdateCapsule(). Firmware sistem UEFI dapat menggunakan proses ini untuk memperbarui sistem dan firmware PC. Dengan memanfaatkan firmware Windows ini mendukung OEM dapat mengandalkan format dan proses umum yang sama untuk memperbarui firmware untuk firmware sistem dan PC. Firmware harus menerapkan tabel ACPI ESRT untuk mendukung UEFI UpdateCapsule() untuk Windows.

  Untuk detail tentang menerapkan dukungan untuk Platform Pembaruan Firmware Windows UEFI, lihat dokumentasi berikut: Platform Pembaruan Firmware Windows UEFI.

  Kapsul pembaruan dapat berada dalam memori atau pada disk. Windows mendukung pembaruan memori.

  1.3.6.1 Kapsul (Kapsul dalam Memori)

  Berikut ini adalah alur peristiwa agar kapsul pembaruan dalam memori berfungsi.

  1. Kapsul dimasukkan ke dalam memori oleh aplikasi di OS
  2. Peristiwa kotak surat diatur untuk menginformasikan BIOS tentang pembaruan yang tertunda
  3. Boot ulang PC, memverifikasi gambar kapsul dan pembaruan dilakukan oleh BIOS

• 1.3.7 Alur kerja pembaruan firmware umum

  1. Unduh dan instal driver firmware.
  2. Mulai ulang.
  3. OS Loader mendeteksi dan memverifikasi firmware.
  4. OS Loader meneruskan blob biner ke UEFI.
  5. UEFI melakukan pembaruan firmware (Proses ini dimiliki oleh vendor silikon).
  6. Deteksi Pemuat OS berhasil diselesaikan.
  7. OS selesai booting.

1.4 Database Tanda Tangan (Db dan Dbx)

• 1.4.1 Database Tanda Tangan yang Diizinkan (db)

  Konten EFI _IMAGE_SECURITY_DATABASE db mengontrol gambar apa yang dipercaya saat memverifikasi gambar yang dimuat. Database mungkin berisi beberapa sertifikat, kunci, dan hash untuk mengidentifikasi gambar yang diizinkan.

  Sertifikat berikut harus disertakan dalam db untuk memungkinkan Pemuat OS Windows dimuat:

1. Windows UEFI CA 2023
   • Hash sertifikasi SHA-1: 45A0FA32604773C82433C3B7D59E7466B3AC0C67.
   • GUID SignatureOwner: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
   • Microsoft akan memberikan sertifikat kepada mitra dan dapat ditambahkan baik sebagai EFI_CERT_X509_GUID tanda tangan jenis atau EFI_CERT_RSA2048_GUID .
   • Windows UEFI CA 2023 dapat diunduh dari sini: https://go.microsoft.com/fwlink/?linkid=2239776.

Kecuali pada sistem yang dikunci untuk mem-boot Windows saja, OEM harus mempertimbangkan untuk menyertakan CA UEFI Pihak Ke-3 dan CA ROM Opsi Microsoft untuk memungkinkan driver dan aplikasi UEFI dari pihak ke-3 berjalan di PC tanpa memerlukan langkah tambahan bagi pengguna.

1. Microsoft Corporation UEFI CA 2011

   • Hash sertifikasi SHA-1: 46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3.
   • GUID SignatureOwner: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
   • Microsoft akan memberikan sertifikat kepada mitra dan dapat ditambahkan baik sebagai EFI_CERT_X509_GUID tanda tangan jenis atau EFI_CERT_RSA2048_GUID .
   • Microsoft Corporation UEFI CA 2011 dapat diunduh dari sini: https://go.microsoft.com/fwlink/p/?linkid=321194.

2. Microsoft UEFI CA 2023

   • Hash sertifikasi SHA-1: B5EEB4A6706048073F0ED296E7F580A790B59EAA.
   • GUID SignatureOwner: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
   • Microsoft akan memberikan sertifikat kepada mitra dan dapat ditambahkan baik sebagai EFI_CERT_X509_GUID tanda tangan jenis atau EFI_CERT_RSA2048_GUID .
   • Microsoft UEFI CA 2023 dapat diunduh dari sini: https://go.microsoft.com/fwlink/?linkid=2239872.

3. Microsoft Option ROM UEFI CA 2023

   • Hash sertifikasi SHA-1: 3FB39E2B8BD183BF9E4594E72183CA60AFCD4277.
   • GUID SignatureOwner: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
   • Microsoft akan memberikan sertifikat kepada mitra dan dapat ditambahkan baik sebagai EFI_CERT_X509_GUID tanda tangan jenis atau EFI_CERT_RSA2048_GUID .
   • Opsi Microsoft ROM UEFI CA 2023 dapat diunduh dari sini: https://go.microsoft.com/fwlink/?linkid=2284009.

• 1.4.2 DbDefault: Vendor platform harus menyediakan serangkaian entri default untuk Database Tanda Tangan dalam variabel dbDefault. Untuk informasi selengkapnya lihat bagian 27.5.3 dalam spesifikasi UEFI.

• 1.4.3 Database Tanda Tangan Terlarang (dbx)

  Konten EFI_IMAGE_SIGNATURE_DATABASE1 dbx harus diperiksa saat memverifikasi gambar sebelum memeriksa db dan kecocokan apa pun harus mencegah gambar dieksekusi. Database mungkin berisi beberapa sertifikat, kunci, dan hash untuk mengidentifikasi gambar terlarang. Persyaratan Sertifikasi Perangkat Keras Windows menyatakan bahwa dbx harus ada, sehingga nilai dummy apa pun, seperti hash SHA-256 , 0dapat digunakan sebagai tempat penampung yang aman hingga waktu seperti Microsoft mulai mengirimkan pembaruan dbx. Klik Di Sini untuk mengunduh daftar pencabutan UEFI terbaru dari Microsoft.

• 1.4.4 DbxDefault: Vendor platform dapat menyediakan serangkaian entri default untuk Database Tanda Tangan dalam variabel dbxDefault. Untuk informasi selengkapnya lihat bagian 27.5.3 dalam spesifikasi UEFI.

1.5 Kunci yang Diperlukan untuk Boot Aman di semua PC

Catatan

OEM perangkat, perusahaan, dan pelanggan dapat menemukan biner PK, KEK, DB, dan DBX yang direkomendasikan Microsoft di repositori sumber terbuka Boot Aman Microsoft. Biner diformat ke format EDKII yang diharapkan untuk dengan mudah diintegrasikan ke dalam firmware.

Nama Kunci/db	Variabel	Pemilik	Catatan
PKpub	PK	OEM	PK – 1 saja. Harus RSA 2048 atau lebih kuat. https://go.microsoft.com/fwlink/?linkid=2255361
Microsoft Corporation KEK 2K CA 2023	KEK	Microsoft	Memungkinkan pembaruan untuk db dan dbx: https://go.microsoft.com/fwlink/p/?linkid=2239775.
Windows UEFI CA 2023	Db	Microsoft	CA dalam Database Tanda Tangan (db) ini memungkinkan Windows untuk melakukan booting: https://go.microsoft.com/fwlink/?LinkId=2239776
Database Tanda Tangan Terlarang	dbx	Microsoft	Daftar Kunci, CA, atau gambar buruk yang diketahui dari Microsoft
Kunci pembaruan firmware yang aman		OEM	Rekomendasinya adalah agar kunci ini berbeda dari PK

Tabel 1: Kunci/db diperlukan untuk Boot Aman

2. Solusi Manajemen Kunci

Di bawah ini diberikan beberapa metrik yang kami gunakan untuk perbandingan.

2.1 Metrik yang digunakan

Metrik berikut dapat membantu Anda memilih PC HSM berdasarkan persyaratan spesifikasi UEFI 2.3.1 Errata C dan kebutuhan Anda.

Terkait Infrastruktur Kunci Umum (PKI)

• Apakah mendukung RSA 2048 atau yang lebih tinggi? - Spesifikasi UEFI 2.3.1 Errata C merekomendasikan kunci menjadi RSA-2048 atau lebih baik.
• Apakah ia memiliki kemampuan untuk menghasilkan kunci dan tanda tangan?
• Berapa banyak kunci yang dapat disimpan? Apakah kunci disimpan di HSM atau server terlampir?
• Metode autentikasi untuk pengambilan kunci. Beberapa PC mendukung beberapa entitas autentikasi untuk hadir untuk pengambilan kunci.

Harga

• Apa poin harganya? HSM dapat berkisar dalam harga dari $ 1.500 hingga $ 70.000 tergantung pada fitur yang tersedia.

Lingkungan manufaktur

• Kecepatan operasi di lantai pabrik. Prosesor kripto dapat mempercepat pembuatan dan akses kunci.
• Kemudahan penyiapan, penyebaran, pemeliharaan.
• Skillset dan pelatihan diperlukan?
• Akses jaringan untuk pencadangan dan Ketersediaan Tinggi

Standar dan Kepatuhan

• Tingkat kepatuhan FIPS apa yang dimilikinya? Apakah tahan terhadap perubahan?
• Dukungan untuk standar lain, misalnya, API kripto MS.
• Apakah memenuhi persyaratan pemerintah dan lembaga lainnya?

Keandalan dan pemulihan bencana

• Apakah memungkinkan Pencadangan Kunci?

  Cadangan dapat disimpan baik di lokasi di lokasi yang aman yang merupakan lokasi fisik yang berbeda dari komputer CA dan HSM dan /atau di lokasi di luar lokasi.

• Apakah memungkinkan Ketersediaan Tinggi untuk pemulihan bencana?

2.2 Opsi Manajemen Kunci

• 2.2.1 Modul Keamanan Perangkat Keras (HSM)

  Berdasarkan kriteria di atas, ini mungkin solusi yang paling cocok dan aman. Sebagian besar HSM memiliki kepatuhan FIPS 140-2 tingkat 3. Kepatuhan FIPS 140-2 tingkat 3 sangat ketat pada autentikasi dan mengharuskan kunci tidak diekspor atau diimpor dari HSM.

  Mereka mendukung beberapa cara penyimpanan kunci. Mereka dapat disimpan baik secara lokal di HSM itu sendiri atau di server yang dilampirkan ke HSM. Di server, kunci dienkripsi dan disimpan dan lebih disukai untuk solusi yang membutuhkan banyak kunci untuk disimpan.

  Kebijakan keamanan modul kriptografi harus menentukan kebijakan keamanan fisik, termasuk mekanisme keamanan fisik yang diterapkan dalam modul kriptografi seperti, segel, kunci, respons perubahan dan pengalih nolisasi, dan alarm. Ini juga memungkinkan menentukan tindakan yang diperlukan oleh operator untuk memastikan bahwa keamanan fisik dipertahankan seperti inspeksi berkala segel yang jelas atau pengujian respons perubahan dan pengalihan nolisasi.

  • 2.2.1.1 Jaringan HSM

    Solusi ini adalah yang terbaik di kelasnya dalam hal keamanan, kepatuhan terhadap standar, pembuatan kunci, penyimpanan, dan pengambilan. Sebagian besar PC ini mendukung ketersediaan tinggi dan memiliki kemampuan untuk mencadangkan kunci.

    Biaya produk ini dapat dalam puluhan ribu dolar berdasarkan layanan tambahan yang mereka tawarkan.

  • 2.2.1.2 HSM Mandiri

    Ini bekerja dengan baik dengan server mandiri. Seseorang dapat menggunakan Microsoft CAPI dan CNG atau API aman lainnya yang didukung oleh HSM. HSM ini hadir dalam berbagai faktor bentuk yang mendukung bus USB, PCIe, dan PCMCIA.

    Mereka secara opsional mendukung pencadangan kunci dan ketersediaan tinggi.

• 2.2.2 Penyedia solusi kustom

  Kriptografi Kunci Umum dapat menantang dan memerlukan pemahaman tentang konsep kriptografi yang mungkin baru. Ada penyedia solusi kustom yang dapat membantu mendapatkan Boot Aman untuk bekerja di lingkungan manufaktur.

  Ada berbagai solusi kustom yang ditawarkan oleh vendor BIOS, perusahaan HSM, dan perusahaan konsultasi PKI untuk mendapatkan Secure Boot PKI bekerja di lingkungan manufaktur.

  Beberapa penyedia tercantum di bawah ini:

  • 2.2.2.1 Vendor BIOS

    Ada beberapa vendor BIOS yang mungkin dapat memberikan solusi kustom.

  • 2.2.2.2 Vendor HSM

    Beberapa vendor HSM mungkin dapat memberikan konsultasi kustom. Untuk informasi selengkapnya, lihat Pembuatan dan Penandatanganan Kunci Boot Aman menggunakan HSM (Contoh).

• 2.2.3 Modul Platform Tepercaya (TPM)

  Modul Platform Tepercaya (TPM) adalah chip perangkat keras pada motherboard yang menyimpan kunci kriptografi yang digunakan untuk enkripsi. Banyak komputer menyertakan TPM, tetapi jika PC tidak menyertakannya, tidak layak untuk menambahkannya. Setelah diaktifkan, Modul Platform Tepercaya dapat membantu mengamankan produk enkripsi disk lengkap seperti kemampuan Microsoft BitLocker. Ini membuat hard drive terkunci, atau disegel, sampai PC menyelesaikan proses verifikasi atau autentikasi sistem.

  TPM dapat menghasilkan, menyimpan, dan melindungi kunci yang digunakan dalam proses enkripsi dan dekripsi.

  Kelemahan TPM adalah mungkin tidak memiliki prosesor kripto yang cepat untuk mempercepat pemrosesan di lingkungan manufaktur. Mereka juga tidak cocok untuk menyimpan sejumlah besar kunci. Pencadangan dan ketersediaan tinggi dan kepatuhan standar terhadap FIPS 140-2 tingkat 3 mungkin tidak tersedia.

• 2.2.4 Kartu Pintar

  Kartu pintar dapat menghasilkan dan menyimpan kunci. Mereka berbagi beberapa fitur yang didukung HSM seperti autentikasi dan pemeriksa masalah, tetapi tidak menyertakan banyak penyimpanan kunci atau cadangan. Mereka memerlukan intervensi manual dan mungkin tidak cocok untuk otomatisasi dan penggunaan di lingkungan produksi karena performanya mungkin rendah.

  Kelemahan kartu Pintar mirip dengan TPM. Mereka mungkin tidak memiliki prosesor kripto yang cepat untuk mempercepat pemrosesan di lingkungan manufaktur. Mereka juga tidak cocok untuk menyimpan sejumlah besar kunci. Pencadangan dan ketersediaan tinggi dan kepatuhan standar terhadap FIPS 140-2 tingkat 3 mungkin tidak tersedia.

• 2.2.5 Sertifikat Validasi diperpanjang

  Sertifikat EV adalah sertifikat jaminan tinggi yang kunci privatnya disimpan dalam token perangkat keras. Ini membantu membangun praktik manajemen kunci yang lebih kuat. Sertifikat EV memiliki kelemahan yang sama dengan Kartu pintar.

• 2.2.6 Pendekatan yang berfokus pada perangkat lunak (TIDAK DISARANKAN)

  Gunakan API kripto untuk manajemen kunci. Ini mungkin melibatkan penyimpanan kunci dalam kontainer kunci pada hard drive terenkripsi dan mungkin untuk sandboxing dan keamanan tambahan menggunakan komputer Virtual.

  Solusi ini tidak seaman menggunakan HSM dan mengekspos vektor serangan yang lebih tinggi.

  2.2.6.1 Makecert (TIDAK DISARANKAN)

  Makecert adalah alat Microsoft dan dapat digunakan sebagai berikut untuk pembuatan kunci. Untuk memastikan bahwa permukaan serangan diminimalkan, Anda mungkin perlu "celah udara" PC. PC yang memiliki PKpriv aktif tidak boleh terhubung ke jaringan. Ini harus berada di lokasi yang aman dan idealnya setidaknya harus menggunakan pembaca kartu pintar jika bukan HSM nyata.

  makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r
  

  Untuk informasi selengkapnya, lihat Alat Pembuatan Sertifikat (Makecert.exe).

  Solusi ini tidak disarankan.

2.3 Pembuatan dan penyimpanan Kunci HSM untuk kunci Boot Aman

• 2.3.1 Menyimpan kunci Privat

  Persyaratan ruang untuk setiap kunci RSA-2048 adalah 2048 bit. Lokasi aktual penyimpanan kunci tergantung pada solusi yang dipilih. HSM adalah cara yang baik untuk menyimpan kunci.

  Lokasi fisik PC di lantai pabrik harus menjadi area yang dilindungi dengan akses pengguna terbatas seperti kandang yang aman.

  Tergantung pada kebutuhan Anda kunci ini juga dapat disimpan di lokasi geografis yang beragam atau dicadangkan di lokasi yang berbeda.

  Persyaratan kunci ulang untuk kunci ini dapat bervariasi berdasarkan pelanggan (lihat Lampiran A untuk panduan kunci ulang otoritas sertifikat jembatan Federal).

  Ini bisa dilakukan sekali per tahun. Anda mungkin perlu memiliki akses ke kunci ini hingga 30 tahun (tergantung pada persyaratan pengulangan dll.).

• 2.3.2 Mengambil Kunci privat

  Kunci mungkin perlu diambil karena berbagai alasan.

  1. PK mungkin perlu diambil untuk menerbitkan PK yang diperbarui karena disusupi atau mematuhi peraturan pemerintah/lembaga lainnya.
  2. KEKpri akan digunakan untuk memperbarui db dan dbx.
  3. Kunci pembaruan firmware yang aman –pri akan digunakan untuk menandatangani pembaruan yang lebih baru.

• 2.3.3 Autentikasi

  Sesuai autentikasi FIPS 140-2 didasarkan pada tingkat akses.

  Tingkat 2

  Tingkat Keamanan 2 mengharuskan, pada autentikasi minimum berbasis peran di mana modul kriptografi mengautentikasi otorisasi operator untuk mengambil peran tertentu dan melakukan serangkaian layanan yang sesuai.

  Tingkat 3

  Tingkat Keamanan 3 memerlukan mekanisme autentikasi berbasis identitas, meningkatkan keamanan yang disediakan oleh mekanisme autentikasi berbasis peran yang ditentukan untuk Tingkat Keamanan 2. Modul kriptografi mengautentikasi identitas operator dan memverifikasi bahwa operator yang diidentifikasi berwenang untuk mengambil peran tertentu dan melakukan serangkaian layanan yang sesuai.

  PC seperti dukungan HSM Tingkat Keamanan 3, yang memerlukan "k autentikasi m" berbasis identitas. Ini berarti entitas k diberikan akses ke HSM dengan token tetapi pada titik tertentu setidaknya k keluar dari token m perlu ada agar autentikasi berfungsi untuk mendapatkan akses ke kunci privat dari HSM.

  Misalnya, Anda dapat memiliki 3 dari 5 token harus diautentikasi untuk mengakses HSM. Anggota tersebut bisa menjadi petugas keamanan, otorisasi transaksi, dan/atau anggota dari Manajemen Eksekutif.

  Token HSM

  Anda dapat memiliki kebijakan tentang HSM yang mengharuskan token hadir:

  • Lokal

  • Jarak jauh

  • Dikonfigurasi untuk diotomatisasi

  Sebagai praktik yang baik, gunakan kombinasi token dan kata sandi per token.

2.4 Boot Aman dan penandatanganan pihak ke-3

• 2.4.1 Penandatanganan driver UEFI

  Driver UEFI harus ditandatangani oleh CA atau kunci di db seperti yang dijelaskan di tempat lain dalam dokumen, atau memiliki hash gambar driver yang disertakan dalam db. Microsoft akan menyediakan layanan penandatanganan driver UEFI yang mirip dengan layanan penandatanganan driver WHQL menggunakan Microsoft UEFI CA 2023. Setiap driver yang ditandatangani oleh ini akan berjalan dengan mulus pada PC apa pun yang menyertakan CA Microsoft UEFI. Dimungkinkan juga bagi OEM untuk menandatangani driver tepercaya dan menyertakan OS OEM di db, atau untuk menyertakan hash driver di db. Dalam semua kasus, driver UEFI (Opsi ROM) tidak akan dijalankan jika tidak dipercaya dalam db.

  Setiap driver yang disertakan dalam gambar firmware sistem tidak perlu diverifikasi ulang. Menjadi bagian dari gambar sistem secara keseluruhan memberikan jaminan yang memadai bahwa driver dipercaya pada PC.

  Microsoft menyediakan ini untuk siapa saja yang ingin menandatangani driver UEFI. Sertifikat ini adalah bagian dari pengujian Boot Aman Windows HCK. Ikuti [blog ini]((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/) untuk membaca selengkapnya tentang kebijakan dan pembaruan penandatanganan CA UEFI.

• 2.4.2 Pemuat boot

  Sertifikat penandatanganan driver Microsoft UEFI dapat digunakan untuk menandatangani OS lainnya. Misalnya, boot loader Linux Fedora akan ditandatangani olehnya.

  Solusi ini tidak memerlukan sertifikat lagi untuk ditambahkan ke Db kunci. Selain hemat biaya, ini dapat digunakan untuk distribusi Linux apa pun. Solusi ini akan berfungsi untuk perangkat keras apa pun yang mendukung Windows sehingga berguna untuk berbagai perangkat keras.

  UEFI-CA dapat diunduh dari sini: https://go.microsoft.com/fwlink/p/?LinkID=321194. Tautan berikut memiliki informasi lebih lanjut tentang penandatanganan dan pengiriman Windows HCK UEFI:

  • Dasbor Perangkat Keras Windows Dev Center
  • Administrasi Dasbor Sertifikasi Windows
  • Penandatanganan Firmware UEFI
  • Blog Sertifikasi Perangkat Keras Windows: Pembaruan CA penandatanganan UEFI

3. Ringkasan dan Sumber Daya

Bagian ini ingin meringkas bagian di atas dan menunjukkan pendekatan langkah demi langkah:

1. Menetapkan CA yang aman atau mengidentifikasi mitra untuk membuat dan menyimpan kunci dengan aman

   Jika Anda tidak menggunakan solusi pihak ke-3:

   1. Instal dan konfigurasikan perangkat lunak HSM di server HSM. Periksa manual referensi HSM Anda untuk instruksi penginstalan. Server akan terhubung ke HSM mandiri atau jaringan.

      Untuk informasi tentang konfigurasi HSM, lihat Bagian 2.2.1, 2.3 dan Lampiran C.

      Sebagian besar HSM menawarkan kepatuhan FIPS 140-2 tingkat 2 dan 3. Konfigurasikan HSM untuk kepatuhan tingkat 2 atau tingkat 3. Kepatuhan tingkat 3 memiliki persyaratan yang lebih ketat sekeliling autentikasi dan akses kunci dan karenanya lebih aman. Tingkat 3 disarankan.

   2. Konfigurasikan HSM untuk Ketersediaan Tinggi, Pencadangan, dan Autentikasi. Periksa manual referensi HSM Anda.

      Ikuti panduan penyedia HSM tentang menyiapkan HSM untuk Ketersediaan Tinggi dan pencadangan.

      Selain itu, HSM Jaringan biasanya memiliki beberapa port jaringan untuk memisahkan lalu lintas; memungkinkan server berkomunikasi dengan HSM jaringan pada jaringan yang terpisah dari jaringan produksi reguler.

      Setelah anggota tim yang merupakan bagian dari tim keamanan telah diidentifikasi dan token ditetapkan kepada mereka. Anda harus menyiapkan perangkat keras HSM untuk autentikasi k-of-m.

   3. Kunci Boot Aman dan pra-pembuatan sertifikat. Lihat Bagian 1.3 hingga 1.5

      Gunakan API HSM untuk membuat (menghasilkan terlebih dahulu) Kunci dan sertifikat Pembaruan PK dan Firmware.

      Diperlukan - PK (merekomendasikan 1 per model), kunci Pembaruan Firmware (merekomendasikan 1 per model), Microsoft KEK, Db, DbxNOTE: Microsoft KEK, db, dan dbx tidak perlu dihasilkan oleh OEM dan disebutkan untuk kelengkapan. Opsional - OEM/pihak ke-3 KEK db, dbx dan kunci lain yang akan masuk ke OEM Db.

2. Terapkan gambar Windows ke PC.

3. Instal Microsoft db dan dbx. Lihat Bagian 1.3.6 dan Lampiran B – API Boot Aman.

   1. Instal Windows UEFI CA 2023 ke db.

   2. Instal dbx kosong jika Microsoft tidak menyediakannya. Windows akan secara otomatis memperbarui DBX ke DBX terbaru melalui Windows Update pada boot ulang pertama.

   Catatan

   Gunakan cmdlet PowerShell yang merupakan bagian dari pengujian Windows HCK atau menggunakan metode yang disediakan oleh vendor BIOS.

4. Instal Microsoft KEK. Lihat Bagian 1.3.3.

   Menginstal Microsoft KEK ke dalam database KEK UEFI

   Perhatian

   Gunakan cmdlet PowerShell yang merupakan bagian dari pengujian Windows HCK atau menggunakan metode yang disediakan oleh vendor BIOS.

5. Langkah opsional - Komponen boot aman pihak ke-3/OEM. Lihat Bagian 1.3.4 dan 1.4.

   1. Identifikasi apakah Anda memiliki kebutuhan untuk membuat OEM/KEK pihak ke-3, db dan dbx.

   2. Tanda tangani OEM/pihak ke-3 db dan dbx dengan OEM/PIHAK ke-3 KEK(dihasilkan sebelumnya) menggunakan HSM API.

   3. Instal OEM/KEK pihak ke-3, db dan dbx.

6. Penandatanganan driver UEFI – Lihat Bagian 2.4.

   Jika mendukung kartu add-in atau driver/aplikasi/bootloader UEFI lainnya, instal Microsoft UEFI CA 2023 dan Microsoft Corporation UEFI CA 2011 ke UEFI db.

7. Kunci pembaruan firmware boot aman - Lihat Bagian 1.3.5.

   1. Pc RT Non-Windows saja: Instal kunci publik pembaruan firmware Aman atau hashnya untuk menghemat ruang.

   2. Hanya di SoC, Anda mungkin perlu melakukan sesuatu yang berbeda, misalnya, membakar kunci pembaruan firmware Aman: publik atau hashnya.

8. Mengaktifkan Boot Aman. Lihat Lampiran B – API Boot Aman.

   1. Instal OEM/ODM PKpub (sertifikat lebih disukai, tetapi kunci tidak apa-apa) ke PK UEFI.

   2. Daftarkan PK menggunakan Secure Boot API. PC sekarang harus diaktifkan untuk Boot Aman.

   Catatan

   Jika Anda menginstal PK di akhir, MS KEK, db, dbx tidak perlu ditandatangani - tidak ada SignerInfo yang harus ada. Ini adalah pintasan.

9. Pengujian Boot Aman: Jalankan pengujian kepemilikan apa pun dan tes Windows HCK sesuai instruksi. Lihat Lampiran B – API Boot Aman.

10. Platform kapal: PKpriv kemungkinan tidak akan pernah digunakan lagi, menjaganya tetap aman.

11. Layanan: Pembaruan firmware di masa mendatang ditandatangani dengan aman dengan kunci "privat" Pembaruan Firmware Aman menggunakan layanan penandatanganan.

3.1 Sumber Daya

Laporan Resmi Strategi Keamanan - https://go.microsoft.com/fwlink/p/?linkid=321288

Pengiriman HCK Windows -https://go.microsoft.com/fwlink/p/?linkid=321287

Lampiran A – Daftar periksa PKI Boot Aman untuk manufaktur

Di bawah ini adalah daftar periksa tingkat tinggi yang meringkas langkah-langkah yang diperlukan untuk mengaktifkan Boot Aman di PC RT non-Windows.

Menyiapkan Boot Aman

1. Tentukan strategi keamanan (identifikasi ancaman, tentukan strategi proaktif dan reaktif) sesuai laporan resmi di bagian 4.

2. Identifikasi tim keamanan sesuai laporan resmi di bagian 4.

3. Buat CA yang aman atau identifikasi mitra (solusi yang direkomendasikan) untuk menghasilkan dan menyimpan kunci dengan aman.

4. Identifikasi kebijakan tentang seberapa sering Anda akan mengulang kunci. Ini mungkin tergantung pada apakah Anda memiliki persyaratan pelanggan khusus seperti pemerintah atau lembaga lain.

5. Memiliki rencana kontingensi jika Kunci Boot Aman disusupi.

6. Identifikasi berapa banyak PK dan kunci lain yang akan Anda buat sesuai bagian 1.3.3 dan 1.5.

   Ini akan didasarkan pada basis pelanggan, solusi penyimpanan utama, dan keamanan PC.

   Anda dapat melewati langkah 7-8 jika Anda menggunakan solusi yang direkomendasikan untuk menggunakan pihak ke-3 untuk manajemen kunci.

7. Mendapatkan server dan perangkat keras untuk manajemen kunci. – jaringan atau HSM mandiri per bagian 2.2.1. Pertimbangkan apakah Anda akan membutuhkan satu atau beberapa HSM untuk ketersediaan tinggi dan strategi pencadangan kunci Anda.

8. Identifikasi setidaknya 3-4 anggota tim yang akan memiliki token autentikasi untuk autentikasi pada HSM.

9. Gunakan HSM atau pihak ke-3 untuk membuat kunci dan sertifikat terkait Boot Aman sebelumnya. Kunci akan tergantung pada jenis PC: SoC, Windows RT atau non-Windows RT. Untuk informasi selengkapnya, lihat Bagian 1.3 hingga 1.5.

10. Isi firmware dengan kunci yang sesuai.

11. Daftarkan Kunci Platform Boot Aman untuk mengaktifkan Boot Aman. Lihat Lampiran B untuk detail selengkapnya.

12. Jalankan pengujian kepemilikan apa pun dan pengujian HCK Secure Boot sesuai instruksi. Lihat Lampiran B untuk detail selengkapnya.

13. Kirim PC. PKpriv kemungkinan tidak akan pernah digunakan lagi, menjaganya tetap aman.

Layanan (Memperbarui firmware)

Anda mungkin perlu memperbarui firmware karena beberapa alasan seperti memperbarui komponen UEFI atau memperbaiki penyusupan kunci Boot Aman atau kunci kunci Boot Aman secara berkala.

Untuk informasi selengkapnya, lihat Bagian 1.3.5 dan bagian 1.3.6.

Lampiran B – API Boot Aman

1. API Boot Aman

   API berikut terkait dengan UEFI/Boot Aman:

   1. GetFirmwareEnvironmentVariableEx: Mengambil nilai variabel lingkungan firmware yang ditentukan.

   2. SetFirmwareEnvironmentVariableEx: Mengatur nilai variabel lingkungan firmware yang ditentukan.

   3. GetFirmwareType: Mengambil jenis firmware.

2. Mengatur PK

   Gunakan cmdlet Set-SecureBootUEFI untuk mengaktifkan Boot Aman. Setelah kode Anda menetapkan PK, penerapan sistem Boot Aman tidak berlaku sampai boot ulang berikutnya. Sebelum reboot, kode Anda dapat memanggil GetFirmwareEnvironmentVariableEx() atau cmdlet PowerShell: Get-SecureBootUEFI untuk mengonfirmasi konten database Boot Aman.

3. Verifikasi

   Anda dapat menggunakan cmdlet Msinfo32.exe atau PowerShell untuk memeriksa status variabel Boot Aman. Tidak ada antarmuka WMI. Anda juga dapat menguji dengan meminta seseorang memasukkan stik USB yang salah ditandatangani yang dapat di-boot (misalnya, dari Tes Logo Manual Boot Aman Windows HCK) dan memverifikasi bahwa ia gagal boot.

4. Cmdlet Powershell Boot Aman

   • Confirm-SecureBootUEFI: Apakah Boot Aman UEFI "ON", True atau False?

     SetupMode == 0 && SecureBoot == 1

   • Set-SecureBootUEFI: Atur atau Tambahkan variabel SecureBoot UEFI yang diautentikasi

   • Get-SecureBootUEFI: Dapatkan nilai variabel SecureBoot UEFI yang diautentikasi

   • Format-SecureBootUEFI: Membuat serialisasi EFI_SIGNATURE_LISTs &EFI_VARIABLE_AUTHENTICATION_2

5. Instruksi Windows HCK dan Boot Aman

   Langkah-langkah berikut berlaku untuk pengujian sistem dan pengujian PC driver non-kelas.

   1. Nonaktifkan perlindungan Boot Aman.

      Masukkan konfigurasi BIOS Anda dan nonaktifkan Boot Aman.

   2. Instal perangkat lunak Klien HCK.

   3. Jalankan semua pengujian HCK Windows, kecuali untuk hal berikut:

      • Tes kata sandi BitLocker TPM dan Recovery dengan PCR[7]
      • TPM BitLocker dan uji kata sandi Pemulihan untuk PC Arm dengan Boot Aman
      • Uji Logo Boot Aman
      • Tes Logo Manual Boot Aman

   4. Masukkan konfigurasi BIOS Anda, aktifkan Boot Aman, dan pulihkan Boot Aman ke konfigurasi Default.

   5. Jalankan pengujian BitLocker dan Secure Boot berikut:

      • Tes kata sandi BitLocker TPM dan Recovery dengan PCR[7]
      • TPM BitLocker dan uji kata sandi Pemulihan untuk PC Arm dengan Boot Aman
      • Pengujian Logo Boot Aman (otomatis)

   6. Masukkan konfigurasi BIOS dan hapus konfigurasi Boot Aman. Ini memulihkan PC ke Mode Penyetelan dengan menghapus PK dan kunci lainnya.

      Catatan

      Dukungan untuk kliring diperlukan untuk PC x86/x64.

   7. Jalankan Pengujian Logo Manual Boot Aman.

      Catatan

      Boot Aman memerlukan driver Windows HCK yang ditandatangani atau VeriSign pada PC RT non-Windows

6. Uji Logo Boot Aman Windows HCK (otomatis)

   Pengujian ini akan memeriksa konfigurasi Boot Aman di luar kotak yang tepat. Drive ini termasuk:

   • Boot Aman Diaktifkan.
   • PK bukan PK tes yang diketahui.
   • KEK berisi Microsoft KEK produksi.
   • db berisi WINDOWS CA produksi.
   • dbx hadir.
   • Banyak variabel 1kB dibuat/dihapus.
   • Variabel 32kB dibuat/dihapus.

7. Tata letak folder uji manual Boot Aman HCK Windows

   Tata letak folder uji Windows HCK Secure Boot Manual Logo dijelaskan di bawah ini:

   • "\Test" folder memiliki hal berikut:

     • Uji Manufaktur dan Layanan
     • Aktifkan Boot Aman secara Terprogram dalam konfigurasi pengujian
     • Uji Layanan
     • Menambahkan sertifikasi ke db, memverifikasi fungsi
     • Menambahkan hash ke dbx, memverifikasi fungsi
     • Menambahkan sertifikasi ke dbx, memverifikasi fungsi
     • Tambahkan 600+ hash ke dbx, verifikasi ukuran
     • Mengubah PK secara terprogram

   • "\Generate" folder memiliki skrip yang menunjukkan hal berikut:

     • Cara sertifikat pengujian dibuat

     • Sertifikat pengujian dan kunci privat disertakan

     • Bagaimana semua pengujian dibuat

     • Mengubah sertifikat dan hash menjadi paket yang ditandatangani

     • Anda dapat menjalankannya sendiri, mengganti sertifikat Anda sendiri

   • "\certs" folder memiliki semua sertifikat yang Anda butuhkan untuk boot Windows:

     Catatan

     Jangan gunakan metodologi yang digunakan untuk "ManualTests\generate\TestCerts" menghasilkan kunci dan sertifikat. Ini dimaksudkan untuk tujuan pengujian Windows HCK saja. Ini menggunakan kunci yang disimpan pada disk yang sangat tidak aman dan tidak disarankan. Ini tidak dimaksudkan untuk digunakan di lingkungan produksi.

• "ManualTests\example\OutOfBox" folder memiliki skrip yang dapat Anda manfaatkan untuk penginstalan Boot Aman pada PC produksi.

  Menunjukkan "ManualTests\generate\tests\subcreate_outofbox_example.ps1" bagaimana contoh ini dihasilkan dan memiliki bagian "TODO" ketika mitra dapat mengganti PK dan metadata lainnya.

8. Penandatanganan dan pengiriman Windows HCK HCK UEFI

   Tautan berikut ini memiliki informasi selengkapnya:

   • Dasbor Pusat Pengembang Perangkat Keras
   • Penandatanganan Firmware UEFI
   • Administrasi Dasbor Sertifikasi Windows
   • Blog Sertifikasi Perangkat Keras Windows: Pembaruan kebijakan Penandatanganan CA Microsoft UEFI

Lampiran C – Pemetaan Jaminan Kebijakan Otoritas Sertifikasi Federal Bridge

1. Dasar

   Tingkat ini memberikan tingkat jaminan terendah mengenai identitas individu. Salah satu fungsi utama tingkat ini adalah memberikan integritas data ke informasi yang sedang ditandatangani. Tingkat ini relevan dengan lingkungan di mana risiko aktivitas berbahaya dianggap rendah. Ini tidak cocok untuk transaksi yang memerlukan autentikasi, dan umumnya tidak mencukupi untuk transaksi yang membutuhkan kerahasiaan, tetapi dapat digunakan untuk yang terakhir di mana sertifikat yang memiliki tingkat jaminan yang lebih tinggi tidak tersedia.

2. Dasar

   Tingkat ini memberikan tingkat jaminan dasar yang relevan dengan lingkungan di mana ada risiko dan konsekuensi dari kompromi data, tetapi mereka tidak dianggap penting. Ini mungkin termasuk akses ke informasi privat di mana kemungkinan akses berbahaya tidak tinggi. Diasumsikan pada tingkat keamanan ini bahwa pengguna tidak mungkin berbahaya.

3.  Sedang

   Tingkat ini relevan dengan lingkungan di mana risiko dan konsekuensi dari kompromi data sedang. Ini mungkin termasuk transaksi yang memiliki nilai moneter yang substansial atau risiko penipuan, atau melibatkan akses ke informasi privat di mana kemungkinan akses berbahaya bersifat substansial.

4. Tinggi

   Tingkat ini sesuai untuk digunakan di mana ancaman terhadap data tinggi, atau konsekuensi dari kegagalan layanan keamanan tinggi. Ini mungkin termasuk transaksi nilai yang sangat tinggi atau tingkat risiko penipuan yang tinggi.

Topik terkait

Pembuatan dan penandatanganan Kunci Boot Aman menggunakan HSM (Contoh)

Panduan Validasi ROM Opsi Validasi UEFI

Gambaran Umum Boot Aman