i.MX HAB ile Secure Boot Zinciri: İmzalama, eFuse ve Doğrulama

NXP'nin i.MX ailesinde secure boot'un temeli, ROM'a gömülü HAB (High Assurance Boot) altyapısıdır. i.MX6, i.MX7 ve i.MX8M türevlerinde kullanılan HABv4, açılışta çalıştırılacak her imajın RSA imzasını, kökü eFuse'lara yazılmış bir SRK hash'ine dayanan sertifika zinciriyle doğrular. Kâğıt üzerinde akış basittir: anahtar üret, imajı imzala, hash'i yak, cihazı kapat. Pratikte ise eFuse'ların tek yönlü olması her hatayı kalıcılaştırır; yanlış yazılmış bir hash cihazı geri dönüşsüz biçimde kilitler. Bu yazıda HABv4 akışını üretim disipliniyle ele alıyoruz: SRK üretimi, bootloader ve kernel imzalama, açık/kapalı cihaz durumları ve alan dönüşü riskleri.

HABv4 güven zinciri nasıl kurulur

Zincirin kökü boot ROM'dur ve değiştirilemez. ROM, boot medyasından okuduğu ilk imajın (i.MX8M'de SPL) IVT'sini bulur, CSF (Command Sequence File) bölümündeki komutları işler ve imzayı SRK tablosuna karşı doğrular. SRK tablosunun kendisi imajın içinde taşınır; ROM'un güvendiği tek şey, bu tablonun SHA-256 özetinin eFuse'lardaki değerle eşleşmesidir. Buradan sonrası yazılımın sorumluluğudur: SPL, hab_auth_img çağrısıyla U-Boot proper + ATF + DTB'yi içeren FIT imajını doğrular; U-Boot da kernel, DTB ve varsa initramfs'i doğrulamadan çalıştırmamalıdır. Zincirin tek bir halkası atlanırsa güvence orada biter — imzalı bir U-Boot'un imzasız kernel yüklemesi secure boot değildir, sadece imzalı bir bootloader'dır.

SRK üretimi: CST ile PKI ağacı

NXP'nin CST (Code Signing Tool) paketi, HAB için gereken PKI ağacını ve SRK tablosunu üretir. Standart kurulum dört SRK içerir; bu, ileride anahtar iptali (revocation) için manevra alanınızdır:

# PKI agacini olustur: 4 adet SRK + her biri icin CSF/IMG sertifikalari
cd cst-3.4.0/keys
./hab4_pki_tree.sh -existing-ca n -kt rsa -kl 4096 \
    -da sha256 -duration 10 -srk-ca y

# SRK tablosu ve eFuse'a yazilacak hash
cd ../crts
../linux64/bin/srktool --hab_ver 4 \
    --table SRK_1_2_3_4_table.bin \
    --efuses SRK_1_2_3_4_fuse.bin \
    --digest sha256 --fuse_format 0 \
    --certs SRK1_sha256_4096_65537_v3_ca_crt.pem,\
SRK2_sha256_4096_65537_v3_ca_crt.pem,\
SRK3_sha256_4096_65537_v3_ca_crt.pem,\
SRK4_sha256_4096_65537_v3_ca_crt.pem

SRK_1_2_3_4_fuse.bin içindeki sekiz word'lük hash, eFuse'lara yazılacak değerdir. Private key'ler bu andan itibaren üretim hattınızın en kritik varlığıdır: offline bir imzalama makinesinde ya da HSM'de tutun, CI pipeline'ına ham anahtar koymayın. İmzalama yetkisini build yetkisinden ayırmak, sızıntı durumundaki tek savunmanızdır.

Bootloader ve kernel imzalama

i.MX8M'de imx-mkimage çıktısı olan flash.bin, SPL ve FIT bölümleri için ayrı CSF blokları gerektirir. Build log'undaki print_fit_hab çıktısı, CSF'teki Authenticate Data bloklarına girecek adres/uzunluk çiftlerini verir; buradaki bir kayma en sık yapılan hatadır ve open device'ta HAB event olarak görünür. CSF şablonlarını cst -i csf_spl.txt -o csf_spl.bin ile işleyip çıktıyı imajın ilgili offset'ine yerleştirirsiniz. Yocto tarafında bu adımları bir imzalama sınıfına bağlamak — her bitbake çıktısının deterministik biçimde imzalanması — elle imzalama kadar sık atlanan bir disiplindir. Kernel tarafında pratik yol, kernel + DTB + initramfs'i tek FIT imajında toplayıp U-Boot'ta CONFIG_IMX_HAB ile gelen hab_auth_img komutuyla doğrulamaktır.

Açık ve kapalı cihaz durumları

Open device geliştirme konforudur: ROM imzayı yine kontrol eder, hataları event olarak biriktirir ama boot'u kesmez. U-Boot'ta hab_status komutu bu event'leri döker; hedef, No HAB Events Found! çıktısıdır. SRK hash'i U-Boot'tan fuse prog -y 6 0 0x... biçiminde yazılır (i.MX8M'de bank 6 ve 7, dörder word). Cihaz, SEC_CONFIG bitini yakan fuse prog -y 1 3 0x2000000 ile kapatılır — bu satırı çalıştırmadan önce open device'ta sıfır HAB event gördüğünüzden emin olun; kapalı cihazda aynı hata, açılmayan bir cihaz demektir.

Alan dönüşü riskleri

Sahaya çıkan kapalı cihazda hata payı yoktur; riskler üretim öncesinde adreslenmelidir:

• Yanlış hash, kalıcı brick. eFuse tek yönlüdür. Hash'i yakmadan önce SRK_1_2_3_4_fuse.bin içeriğini bağımsız biçimde çapraz doğrulayın (ör. srktool çıktısını ikinci bir makinede yeniden üretip hexdump ile karşılaştırmak); üretim hattında fuse yazımını insan eline değil, her adımı loglayan bir fixture'a verin.
• Anahtar sızıntısı ve revocation. Dört SRK'den aktif olmayanlar SRK_REVOKE fuse'ları ile iptal edilebilir; toplamda üç yedeğiniz vardır. CSF'te Unlock komutuyla SRK_REVOKE yazımının serbest bırakılması gerektiğini unutmayın — aksi halde sahada iptal şansınız hiç olmaz.
• İmzasız güncelleme yolu. Zincir, OTA ile gelen her imaj için de geçerli olmalıdır; imzasız bir recovery yolu bırakmak zinciri anlamsızlaştırır. A/B şema, imza doğrulaması ve rollback koruması birlikte tasarlanmalıdır — bu hattın kurulumunu secure boot ve OTA güncelleme yeteneği altında ayrıntılı ele alıyoruz.
• Açılış süresi etkisi. RSA-4096 doğrulaması ve FIT hash kontrolleri açılış süresine ölçülebilir yük ekler; Falcon mode gibi optimizasyonlarla birlikte planlanmalıdır, çünkü SPL'den kernel'e doğrudan atlarken doğrulama adımı zincirden düşmemelidir. Boot süresi bütçesinin nasıl kurulduğuna dair bir örnek için i.MX8M Plus boot optimizasyonu vaka analizine bakabilirsiniz.
• RMA süreci. FIELD_RETURN fuse'u, dönen cihazlarda HAB'ı devre dışı bırakıp analiz yapmayı sağlar; ancak bu fuse'un yazılabilmesi de CSF'te açıkça serbest bırakılmalıdır ve süreç, hangi cihazın hangi gerekçeyle açıldığını kayıt altına almalıdır.

Encrypted boot (DEK blob ile imaj şifreleme) bu yazının kapsamı dışında; yine de imza olmadan şifrelemenin bütünlük garantisi vermediğini, iki mekanizmanın farklı tehditleri adreslediğini not edelim.

Secure boot tek seferlik bir imzalama adımı değil; anahtar yönetimi, üretim hattı ve güncelleme stratejisiyle birlikte kurulan bir sistemdir — mevcut boot zincirinizi ve fuse stratejinizi üretime çıkmadan gözden geçirmek isterseniz gömülü sistem mimari denetimi bunun için doğru başlangıç noktasıdır.