Spesifikasi Uji Coba Keamanan Perangkat Keras

  • Artikel

Pengenalan

HSTI melindungi dari kesalahan konfigurasi fitur keamanan pada perangkat Windows. Bagi pelanggan, HSTI memberikan jaminan upaya terbaik bahwa mesin yang telah mereka beli aman secara default. Untuk IHV dan IBV, HSTI memastikan janji keamanan Anda ditepati. Untuk OEM dan ODM dengan mudah memastikan bahwa sistem yang Anda kirim dikonfigurasi dengan aman dan akan tetap aman, tanpa harus mengembangkan solusi kepemilikan.

Hasil pengujian HSTI akan digunakan oleh Tes Kompatibilitas Windows dan dapat digunakan untuk memverifikasi bahwa perangkat telah dikonfigurasi dengan benar untuk mengaktifkan fitur keamanan yang didukung. Pengujian ini dapat digunakan untuk mengidentifikasi perangkat rekayasa yang tidak aman di lapangan, misalnya, perangkat rekayasa yang mungkin berisi kunci pengujian yang tidak aman. Hasil pengujian ini dapat digunakan oleh OS Windows untuk menampilkan marka air (atau indikator serupa) pada perangkat yang tidak aman.

Catatan

  Platform ini diperlukan untuk menerapkan antarmuka perangkat keras dan berbagi dokumentasi dan alat seperti yang ditentukan dalam topik ini.

Latar belakang

Pembaca diharapkan mengetahui dasar-dasar UEFI dan memiliki pemahaman tentang teknologi Boot Aman termasuk Bagian 27 "Keamanan" spesifikasi UEFI dan NIST SP 800-147.

Persyaratan ini memiliki tiga aspek:

  • Antarmuka independen platform untuk mengkueri status keamanan perangkat keras dan firmware
  • Desain dan tinjauan kode opsional dari implementasi antarmuka di atas
  • Berbagi dokumentasi dan alat

Implementasi Tingkat Tinggi

Ladang Bit

IHV mendefinisikan bitfield yang mewakili fitur keamanan platform yang dapat diuji. Bitfield ini sepenuhnya mencakup semua bit yang dapat ditentukan yang tersedia untuk objek HSTI yang dikembalikan oleh tes IHV, IBV, atau OEM HSTI apa pun. Implementor IHV harus merancang definisi bitfield dan memberikan dokumentasi yang sesuai agar IBV mengembalikan hasil pengujian HSTI mereka dengan benar.

SecurityFeaturesRequired

Bidang SecurityFeaturesRequired hanya digunakan dalam pemrosesan ketika bidang dalam objek IHV HSTI dan merupakan metode di mana IHV mendefinisikan bitfield fitur keamanan yang diperlukan.

SecurityFeaturesImplemented

Ini adalah bitfield dari fitur keamanan yang diterapkan oleh pengujian yang mengembalikan objek HSTI.

SecurityFeaturesVerified

Ini adalah bitfield dari fitur keamanan yang telah diverifikasi oleh pengujian yang mengembalikan objek HSTI.

Pedoman Implementasi

IHV akan mengembangkan desain keamanan referensi untuk platform mereka yang mematuhi Persyaratan Kompatibilitas Windows. Selain itu, IHV dan IBV juga akan menerapkan pengujian terprogram yang memverifikasi pengaktifan implementasi keamanan referensi yang tepat dan melaporkan hasilnya melalui Antarmuka Uji Keamanan Perangkat Keras. Pengujian ini dikirimkan ke OEM & ODM sebagai modul yang dikompilasi (bukan sumber) dan harus berfungsi tanpa modifikasi. Jika OEM/ODM menyimpang dari desain keamanan referensi, modul pengujian ini dapat melaporkan kegagalan, dan OEM/ODM perlu menghubungi Microsoft untuk meninjau modifikasi dan menerapkan instans HSTI tambahan yang melaporkan pengecualian ini. OEM harus dapat memanfaatkan modul keamanan ini tanpa modifikasi yang diperlukan dengan mengikuti desain referensi dan dokumentasi. OEM yang ingin menambahkan modul keamanan tambahan, atau memodifikasi perilaku modul keamanan apa pun, harus menjalani tinjauan desain dengan Microsoft.

Sebagai bagian dari implementasi implementor modul pengujian mereka akan mencakup struct. Prototipe dari struktur ini disertakan di bawah ini di "bagian Prototipe". IHV akan menentukan arti setiap bit dalam daftar periksa referensi keamanan. IHV akan lebih mendefinisikan arti setiap bit di bitfields. Akhirnya, IHV menyertakan bitfield "Diperlukan" dalam struktur OEM, dan untuk semua persyaratan mereka dapat menguji secara terprogram mereka akan mengatur sedikit di bitfield "Diimplementasikan".

IBV dan OEM dapat mengatur bit di bidang "Diimplementasikan" jika mereka telah menyajikan desain untuk secara progamatis memeriksa keberadaan fitur keamanan yang diwakili oleh bit tersebut kepada Microsoft. Jika pengujian tersebut lulus, mereka dapat mengatur bidang "Terverifikasi" di struktur masing-masing.

Modul pengujian untuk IHV, IBV, dan OEM akan dijalankan jika ada. Nilai benar yang ditetapkan sedikit di bidang SecurityFeaturesEnabled menunjukkan hasil pengujian yang lulus. Jika pengujian tidak dijalankan, atau tidak lulus, nilai 0 harus ditetapkan untuk bit perwakilan.

Contoh Logika Pemrosesan Hasil

Contoh ini mewakili logika yang akan digunakan oleh pemrosesan hasil. Bitfield yang diimplementasikan harus mengikuti format yang berarti 1 diimplementasikan dan 0 berarti tidak diimplementasikan. Jika sesuatu diimplementasikan, diperlukan. Ladang bit hasil harus mengikuti format bahwa 0 berarti gagal atau pengujian tidak ada dan 1 berarti hanya diteruskan secara afirmatif.

Setelah semua hasil dihitung, bitfield Hasil IHV akan menjadi NXORd dengan bitfield yang Diperlukan. Semua bitfield Hasil non-IHV diANDed dengan bitfield yang Diimplementasikan masing-masing. Bitfield yang dihasilkan adalah semua ORd bersama-sama untuk mendapatkan hasil keseluruhan. Hasil yang lewat dari operasi ini akan menjadi bitfield yang terdiri dari sepenuhnya 1s.

Hasil Dan Kepemilikan

Vendor Perangkat Keras Independen (IHV) dan Vendor BIOS Independen (IBV)

Pemasok Silikon dan IBV yang mendukung sistem Siaga Koneksi harus menerapkan antarmuka independen platform untuk mengkueri status keamanan perangkat keras dan firmware masing-masing dari platform referensi mereka. Implementasi ini harus dikirimkan sebagai modul yang dikompilasi. Lebih disukai bahwa modul ini ditandatangani, dan pemeriksaan tanda tangan dilakukan saat dijalankan. Tujuannya adalah untuk mengkueri desain perangkat keras dan firmware & status untuk melaporkan provisi keamanan platform yang tepat.

OEM dan ODM

OEM dan ODM tidak boleh memodifikasi atau mengubah pengujian HSTI yang telah diberikan kepada mereka oleh vendor. OEM dan ODM diperlukan untuk menjamin bahwa sistem mereka akan lulus tes HSTI sebagai komponen dari persyaratan Sertifikasi Windows:

Persyaratan Sertifikasi Perangkat Keras Windows - WINDOWS 8.1 WHCR

  • System.Fundamentals.Firmware.UEFISecureBoot
  • System.Fundamentals.Firmware.CS.UEFISecureBoot. Koneksi edStandby

Alih-alih modifikasi, jika OEM memerlukan metode untuk menyediakan metode alternatif untuk memberikan keamanan yang sama atau lebih baik, OEM dapat memberikan pemeriksaan keamanan tambahan. Pemeriksaan keamanan OEM setidaknya harus sepenuhnya mencakup satu tes keamanan IHV atau IBV. Sebelum digunakan, OEM harus mengirimkan ke tinjauan desain oleh Microsoft dan tunduk pada persyaratan pengungkapan Dokumentasi dan Alat yang sama dengan penyedia uji HSTI lainnya. Setelah disetujui dari Microsoft, OEM dapat mencakup pengujian keamanan yang diperluas pada tes IHV dan IBV.

Perhatikan bahwa pengesahan OEM tidak diperlukan sebagai bagian dari desain HSTI. HSTI bukan daftar persyaratan untuk OEM, ini adalah antarmuka untuk menjamin pengujian keamanan terprogram yang efektif dari parameter firmware, perangkat keras, dan konfigurasi.

Antarmuka Status Keamanan

Antarmuka dibangun pada Protokol Informasi Adaptor EFI yang ditentukan dalam UEFI versi 2.4.

Antarmuka Status Keamanan Platform

Ringkasan

Informasi Keamanan Platform - Mengembalikan informasi tentang kesesuaian platform dengan Windows Hardware Certification Requirement System.Fundamentals.Firmware.CS.UEFISecureBoot, System.Fundamentals.Firmware.CS.UEFISecureBoot.KoneksiedStandby dan System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning.

Prototipe

InformationType

#define ADAPTER_INFO_PLATFORM_SECURITY_GUID \
     {0x6be272c7, 0x1320, 0x4ccd, { 0x90, 0x17, 0xd4, 0x61, 0x2c, 0x01, 0x2b, 0x25 }}

#define PLATFORM_SECURITY_VERSION_VNEXTCS   0x00000003

#define PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE   0x00000001  // IHV
#define PLATFORM_SECURITY_ROLE_PLATFORM_IBV 0x00000002
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_OEM 0x00000003 
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_ODM  0x00000004

InformationBlock yang sesuai:

typedef struct { 
    UINT32  Version,
    UINT32  Role,
    CHAR16  ImplementationID[256],
    UINT32  SecurityFeaturesSize,
    UINT8   SecurityFeaturesRequired[],     //Ignored for non-IHV
    UINT8   SecurityFeaturesImplemented[],
    UINT8   SecurityFeaturesVerified[],
    // CHAR16   ErrorString[];
} ADAPTER_INFO_PLATFORM_SECURITY;
Persyaratan Deskripsi

Versi

Mengembalikan PLATFORM_SECURITY_VERSION_VNEXTCS

Peran

Peran penerbit antarmuka ini. Perancang platform referensi seperti IHV dan IBV diharapkan untuk mengembalikan PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE dan PLATFORM_SECURITY_ROLE_PLATFORM_IBV masing-masing. Jika modul pengujian dari perancang tidak dapat sepenuhnya memverifikasi semua fitur keamanan, maka pelaksana platform, OEM, dan ODM, perlu menerbitkan antarmuka ini dengan peran Implementer.

ImplementationID

Vendor, model, & versi implementasi yang dapat dibaca manusia. Misalnya "SiliconVendorX Chip1234 v1" dan "BIOSvendorY BIOSz v2".

SecurityFeaturesSize

Ukuran dalam byte array SecurityFeaturesRequired dan SecurityFeaturesEnabled. Array harus berukuran sama.

SecurityFeaturesRequired

Bitfield yang ditentukan IHV yang sesuai dengan semua fitur keamanan yang harus diimplementasikan untuk memenuhi persyaratan keamanan yang ditentukan oleh versi PLATFORM_SECURITY_VERSION. Misalnya, 7 fitur mungkin diperlukan untuk diimplementasikan untuk memenuhi Versi, nilai 0b01111111 mungkin dilaporkan.

SecurityFeaturesImplemented

Bitfield yang ditentukan penerbit sesuai dengan semua fitur keamanan yang telah menerapkan pengujian terprogram dalam modul ini.

SecurityFeaturesVerified

Bitfield yang ditentukan penerbit sesuai dengan semua fitur keamanan yang telah diverifikasi yang diimplementasikan oleh implementasi ini.

ErrorString

String yang dihentikan null, satu kegagalan per baris (CR/LF dihentikan), dengan pengidentifikasi unik yang dapat digunakan OEM/ODM untuk menemukan dokumentasi yang akan menjelaskan langkah-langkah untuk memulihkan kegagalan - URL ke dokumentasi direkomendasikan. Misalnya: 

0x4827 JTAG not disabled http://somewhere.net/docs/remediate4827.html \r\n0x2744 Platform Secure Boot key not provisioned http://somewhere.net/docs/remediate2744.html

Pertimbangan Manajemen Memori

Untuk tujuan kompatibilitas antara modul HSTI, implementor harus menggunakan AllocatePool() dan bukan AllocatePages().

Tinjauan desain Implementasi HSTI

Microsoft harus melakukan tinjauan desain awal dari semua implementasi antarmuka pengujian. Contoh pertanyaan yang mungkin diajukan dalam tinjauan desain disediakan di bagian Pertimbangan Desain HSTI.

Tinjauan Kode Opsional

Pelaksana HSTI dapat meminta tinjauan kode yang dilakukan oleh Microsoft. Tinjauan kode dapat diberikan berdasarkan prioritas dan ketersediaan sumber daya dan tidak dijamin. Tinjauan kode akan dilakukan tunduk pada Perjanjian Non Pengungkapan.

Berbagi Dokumentasi dan Alat

Pemasok silikon dan firmware harus tersedia untuk Microsoft semua dokumentasi dan alat referensi terkait keamanan yang diperlukan yang mereka berikan kepada OEM. Dokumentasi dan alat ini harus tersedia tidak lebih lambat dari yang disediakan untuk OEM Windows. Ini harus mencakup, tetapi tidak terbatas pada, semua dokumentasi dan alat yang terkait dengan fusing, menginstal dan memperbarui firmware, firmware dan pemulihan boot, diagnostik perangkat keras, diagnostik firmware, & diagnostik boot. Dokumentasi dan alat yang disediakan ini harus sepenuhnya cukup untuk melakukan pemeriksaan HSTI di lingkungan lab.

Pertimbangan Desain HSTI

Berikut ini adalah daftar ilustrasi pertimbangan desain yang harus dipertimbangkan oleh implementor HSTI untuk implementasi HSTI mereka. Ini bukan daftar persyaratan yang ketat, juga bukan daftar pertimbangan lengkap. Sebagai implementor HSTI, Anda akan menulis tes untuk memvalidasi fitur keamanan yang telah Anda kerjakan sesering mungkin. Sebelum tinjauan desain Anda dengan Microsoft, kami sarankan Anda meninjau daftar ini untuk inspirasi, dan pertimbangkan bahwa Microsoft cenderung menginginkannya jika Anda menerapkan fitur-fitur ini, Anda mengujinya secara ekstensif mungkin.

Pemeriksaan HSTI Pemasok Silikon/Vendor (IHV)

  1. Apakah Anda hanya menggunakan RSA 2048 dan SHA256 (atau kekuatan kripto serupa)
  2. Kode Firmware harus ada di penyimpanan yang dilindungi
    1. Apakah Anda melindungi spiflash?
    2. Apakah Anda menerapkan baca-saja sampai reset untuk partisi eMMC
    3. Apakah Anda mendukung Pemeriksaan Firmware Bertanda Tangan - Firmware yang diinstal oleh OEM bersifat baca-saja atau dilindungi oleh proses pembaruan firmware yang aman.
  3. Mengamankan proses pembaruan firmware
    1. Apakah proses pembaruan firmware aman aktif secara default dengan kunci pengujian? (DISARANKAN)
    2. Apakah Anda memeriksa apakah kunci pengujian digunakan dalam produksi?
    3. Apakah Anda mengizinkan pemutaran kembali ke versi firmware yang tidak aman? Jika ya, apa mekanisme perlindungannya? Apakah Anda menghapus TPM saat pemutaran kembali terjadi?
  4. Apakah Anda memiliki backdoor untuk mengambil alih SecureBoot
    1. Apakah sistem Anda mendukung permintaan sebaris untuk melewati Secureboot? Jika ya, apakah dinonaktifkan saat SecureBoot diaktifkan?
    2. Apakah Anda memiliki backdoor manufaktur? Apakah Anda memeriksanya untuk dinonaktifkan saat SecureBoot diaktifkan dan selalu dinonaktifkan dalam sistem produksi?
  5. [CS] Dukungan Integritas Boot
    1. Apakah Anda mendukung Integritas Boot dan apakah diaktifkan secara default?
    2. Platform menggunakan memori on-die ROM atau One-Time Programmable (OTP) untuk menyimpan kode boot awal dan menyediakan logika reset daya-on untuk dieksekusi dari ROM on-die atau SRAM on-die yang aman.
  6. [CS] Perlindungan dari DMA internal dan eksternal
    1. Apakah Anda tetap mengaktifkan DMA internal hanya untuk komponen yang diperlukan selama boot? Dan dinonaktifkan untuk semua komponen lainnya.
    2. Apakah Anda tetap mengaktifkan DMA eksternal hanya untuk komponen yang diperlukan selama boot? Dan dinonaktifkan untuk semua komponen lainnya.
    3. Jika firmware memiliki opsi untuk mengaktifkan dan menonaktifkan perlindungan DMA, konfigurasi pengiriman harus mengaktifkan perlindungan DMA secara default
    4. Bus/perangkat apa (sekering, mesin keamanan, TZ, video, cache, IMEM, memori kernel) yang mampu mengakses DMA ke wilayah penyimpanan NV dan volatil yang berbeda dan bagaimana mereka dilindungi?
    5. Apakah Anda mendukung implementasi bit MOR
  7. Perlindungan terhadap debugger perangkat keras eksternal
    1. Apakah Anda mendukung JTAG? Apakah JTAG NONAKTIF saat SecureBoot AKTIF
    2. Apakah Anda menyediakan backdoor manufaktur untuk menonaktifkan perlindungan JTAG? Apakah Anda memeriksa apakah backdoor ini tidak ada dalam sistem produksi?
    3. Apakah Anda menghapus TPM saat JTAG diaktifkan?
    4. Apakah Anda mendukung debugger perangkat keras lainnya? Dan lakukan pemeriksaan yang sama untuk itu.
  8. Apakah Anda telah menyediakan rahasia unik per perangkat dengan benar?
  9. Apa saja sekering keamanan yang Anda miliki (khusus vendor)
    1. SOC SecureBoot fuse
    2. Rahasia unik per perangkat seperti dukungan atau sekering ensiferensi
    3. Sekering JTAG
    4. Sekering SecureBoot Prosesor Aplikasi SOC
    5. Sekering SecureBoot Prosesor SOC MBA
    6. Sekering SecureBoot Prosesor Modern SOC
    7. Sekering spesifik SOC lainnya untuk platform Anda

Pemeriksaan IBV HSTI

  1. Apakah Anda menggunakan RSA 2048 dan SHA256 saja (atau lebih tinggi tetapi tidak lebih rendah dari ini)
  2. Modul Dukungan Kompatibilitas (CSM)
    1. Apakah Anda menyediakan opsi untuk mengaktifkan CSM
    2. Apakah Anda memeriksa pemblokiran pemuatan CSM saat SecureBoot diaktifkan
    3. [CS] Apakah Anda memeriksa apakah CSM tidak ada di sistem CS secara permanen
  3. Kode Firmware harus ada di penyimpanan yang dilindungi
    1. Apakah Anda melindungi spiflash?
    2. Apakah Anda menerapkan baca-saja sampai reset untuk partisi eMMC
    3. Apakah Anda mendukung Pemeriksaan Firmware Bertanda Tangan - Firmware yang diinstal oleh OEM bersifat baca-saja atau dilindungi oleh proses pembaruan firmware yang aman.
  4. Mengamankan proses pembaruan firmware
    1. Apakah proses pembaruan firmware aman aktif secara default dengan kunci pengujian?
    2. Apakah Anda memeriksa apakah kunci pengujian digunakan dalam produksi?
    3. Apakah Anda mengizinkan pemutaran kembali ke versi firmware yang tidak aman? Jika ya, apa mekanisme perlindungannya? Apakah Anda menghapus TPM saat pemutaran kembali terjadi?
    4. Apakah kunci pengujian sedang digunakan?
  5. Apakah Anda memiliki backdoor untuk mengambil alih SecureBoot
    1. Apakah sistem Anda mendukung permintaan sebaris untuk melewati Secureboot? Jika ya, apakah dinonaktifkan saat SecureBoot diaktifkan?
    2. Apakah Anda memiliki backdoor manufaktur? Apakah Anda memeriksanya untuk dinonaktifkan saat SecureBoot diaktifkan dan selalu dinonaktifkan dalam sistem produksi?
  6. [CS] Perlindungan dari DMA internal dan eksternal
    1. Apakah Anda tetap mengaktifkan DMA internal hanya untuk komponen yang diperlukan selama boot? Dan dinonaktifkan untuk semua komponen lainnya.
    2. Apakah Anda tetap mengaktifkan DMA eksternal hanya untuk komponen yang diperlukan selama boot? Dan dinonaktifkan untuk semua komponen lainnya.
    3. Jika firmware memiliki opsi untuk mengaktifkan dan menonaktifkan perlindungan DMA, konfigurasi pengiriman harus mengaktifkan perlindungan DMA secara default
    4. Bus/perangkat apa (sekering, mesin keamanan, TZ, video, cache, IMEM, memori kernel) yang mampu mengakses DMA ke wilayah penyimpanan NV dan volatil yang berbeda dan bagaimana mereka dilindungi?
    5. Apakah Anda mendukung implementasi bit MOR