00 Güven zinciri ve tehdit modeli
Secure Boot'un amacı, sistem açılış sürecinin her adımında yetkisiz veya değiştirilmiş yazılımın çalıştırılmasını engellemektir.
Boot chain: ROM'dan init'e
Güven zinciri, fabrikada programlanan ve değiştirilemez olan ROM bootrom'dan başlar. Her aşama bir sonraki aşamanın kriptografik imzasını doğrular; doğrulama başarısız olursa boot durur.
ROM bootrom (immutable, SoC içi)
│ ↳ public key hash OTP fuse'da saklı
▼
SPL / FSBL (imzalı)
│ ↳ ROM tarafından doğrulandı
▼
U-Boot (imzalı FIT veya HAB ile korunan)
│ ↳ SPL tarafından doğrulandı
▼
Linux Kernel + DTB (FIT image içinde imzalı)
│ ↳ U-Boot tarafından doğrulandı
▼
Init / systemd (dm-verity ile korunan rootfs'ten)
│ ↳ Kernel hash tree doğrulaması
Tehdit modeli
| Tehdit | Saldırı vektörü | Karşı önlem |
|---|---|---|
| Fiziksel erişim | Flash'a trojanize firmware yazma, JTAG debug | HAB fuse (JTAG devre dışı), Secure Boot |
| Yazılım saldırısı | OTA güncellemede kötü amaçlı image | FIT imza doğrulama, rollback counter |
| Supply chain | Üretim sürecinde değiştirilmiş binary | SRK hash fuse, reproducible build |
| Rootfs manipülasyonu | Çalışan sistemde dosya sistemi değiştirme | dm-verity, read-only rootfs |
| Ölçüm sahteciliği | TPM PCR değerlerini sahte raporlama | Remote attestation, signed quote |
Güven kökleri
Secure Boot, şifreleme değildir — bütünlük ve özgünlük doğrulamasıdır. Disk şifreleme (dm-crypt, LUKS) ile birleştirildiğinde hem bütünlük hem gizlilik sağlanır. Bunlar birbirini tamamlayan farklı güvenlik katmanlarıdır.
Bu bölümde
- Güven zinciri ROM'dan başlar; her aşama bir sonrakini doğrular
- OTP fuse değiştirilemez fiziksel güven köküdür
- Tehdit modeli: fiziksel erişim, yazılım saldırısı, supply chain, rootfs manipülasyonu
- Secure Boot = bütünlük; dm-crypt = gizlilik; ikisi birlikte kullanılabilir
01 Asimetrik imzalama temelleri
Secure Boot, asimetrik kriptografi üzerine kuruludur: private key ile imzala, public key ile doğrula — doğrulama tarafı private key'i asla görmez.
Algoritma karşılaştırması
| Algoritma | Anahtar boyutu | İmza boyutu | Güvenlik | Performans |
|---|---|---|---|---|
| RSA-2048 | 2048 bit | 256 byte | 112-bit eşdeğer | Orta; yaygın |
| RSA-4096 | 4096 bit | 512 byte | 140-bit eşdeğer | Yavaş; uzun vadeli |
| ECDSA P-256 | 256 bit | 64 byte | 128-bit eşdeğer | Hızlı; küçük imza |
| ECDSA P-384 | 384 bit | 96 byte | 192-bit eşdeğer | Hızlı; yüksek güvenlik |
| Ed25519 | 256 bit | 64 byte | 128-bit eşdeğer | Çok hızlı; modern |
Anahtar üretimi ve sertifika
# RSA-2048 private key üret
openssl genrsa -out dev.key 2048
# RSA-4096 private key (daha uzun vadeli)
openssl genrsa -out prod.key 4096
# ECDSA P-256 (küçük cihazlar için ideal)
openssl ecparam -name prime256v1 -genkey -noout -out ec.key
# Self-signed X.509 sertifikası üret (10 yıl geçerli)
openssl req -new -x509 \
-key dev.key \
-out dev.crt \
-days 3650 \
-subj "/CN=Embedded Secure Boot Key/O=MyCompany/C=TR"
# Sertifikayı DER formatına dönüştür (U-Boot için)
openssl x509 -in dev.crt -outform DER -out dev.crt.der
# Public key'i DER olarak çıkar
openssl rsa -in dev.key -pubout -outform DER -out dev.pub.der
# İmza doğrulama — manuel test
openssl dgst -sha256 -sign dev.key -out image.sig image.bin
openssl dgst -sha256 -verify dev.pub.der -signature image.sig image.bin
PEM ve DER formatları
Hash algoritması seçimi
# SHA-256: en yaygın, U-Boot ve HAB tarafından desteklenir
openssl dgst -sha256 image.bin
# SHA-384: daha yüksek güvenlik seviyesi
openssl dgst -sha384 image.bin
# SHA-512: TPM PCR extend için de kullanılır
openssl dgst -sha512 image.bin
# MD5 KULLANMAYIN — güvenlik uygulamaları için cryptographically broken
Private key'leri güvenli bir HSM (Hardware Security Module) veya en azından şifrelenmiş bir vault'ta saklayın. Build sunucusunda plain-text private key bırakmayın. Üretim key'leri için ayrı, air-gapped bir imzalama ortamı kullanmayı düşünün.
Bu bölümde
- RSA-2048 yaygın; ECDSA P-256 küçük imza ve hız için; Ed25519 modern alternatif
openssl genrsa -out dev.key 2048veopenssl req -x509ile sertifika üretimi- PEM: metin, insan okunabilir; DER: binary, bootloader araçları için
- Hash: SHA-256 minimum, SHA-384 yüksek güvenlik için
02 U-Boot FIT image imzalama
FIT (Flattened Image Tree) formatı, kernel, DTB ve ramdisk'i tek bir imzalı pakette birleştirir; U-Boot bu paketin imzasını doğrulayarak güvenli boot sağlar.
FIT image anatomisi — ITS dosyası
/dts-v1/;
/ {
description = "Signed kernel + dtb + ramdisk";
#address-cells = <1>;
images {
kernel@1 {
description = "Linux Kernel";
data = /incbin/("zImage");
type = "kernel";
arch = "arm";
os = "linux";
compression = "none";
load = <0x80008000>;
entry = <0x80008000>;
hash@1 {
algo = "sha256";
};
};
fdt@1 {
description = "MyBoard Device Tree";
data = /incbin/("myboard.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
hash@1 {
algo = "sha256";
};
};
ramdisk@1 {
description = "Initial ramdisk";
data = /incbin/("initrd.cpio.gz");
type = "ramdisk";
arch = "arm";
os = "linux";
compression = "gzip";
hash@1 {
algo = "sha256";
};
};
};
configurations {
default = "conf@1";
conf@1 {
description = "Boot config with signature";
kernel = "kernel@1";
fdt = "fdt@1";
ramdisk = "ramdisk@1";
signature@1 {
algo = "sha256,rsa2048";
key-name-hint = "dev";
sign-images = "kernel", "fdt", "ramdisk";
};
};
};
};
FIT image oluşturma ve imzalama
# Anahtar dizini oluştur
mkdir -p keys/
openssl genrsa -out keys/dev.key 2048
openssl req -new -x509 -key keys/dev.key -out keys/dev.crt \
-days 3650 -subj "/CN=FIT Signing Key"
# FIT image oluştur ve imzala
# -f: ITS dosyası
# -k: anahtar dizini (dev.key ve dev.crt burada)
# -K: public key'in gömüleceği U-Boot DTB
# -r: required (doğrulama zorunlu kıl)
mkimage -f my.its -k keys/ -K u-boot.dtb -r my.fit
# İmzalanmış FIT'i doğrula
mkimage -l my.fit
# FIT description: Signed kernel + dtb + ramdisk
# ... Signature: sha256,rsa2048:dev OK
# U-Boot DTB'ye gömülmüş public key'i doğrula
fdtdump u-boot.dtb | grep -A 5 "signature"
U-Boot Kconfig — FIT imza desteği
# FIT imza doğrulama
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y # doğrulama detaylarını logla
CONFIG_RSA=y
CONFIG_RSA_SOFTWARE_EXP=y # yazılım RSA (donanım yoksa)
CONFIG_SHA256=y
# Sadece imzalı image'a izin ver (unsigned image'ı reddet)
CONFIG_IMAGE_FORMAT_LEGACY=n # eski mkimage formatını devre dışı bırak
# U-Boot ortam değişkeni: sadece verified boot
# bootcmd=bootm ${loadaddr}#conf@1
Public key, mkimage -K u-boot.dtb komutuyla U-Boot'un kendi DTB'sine gömülür. Bu DTB daha sonra U-Boot binary'siyle birleştirilerek flash'a yazılır. Böylece U-Boot her boot'ta aynı public key'le doğrulama yapar — key'i ayrı bir partition'da tutmaya gerek yoktur.
Bu bölümde
- ITS dosyası: kernel + DTB + ramdisk + imza konfigürasyonunu tanımlar
mkimage -f my.its -k keys/ -K u-boot.dtb -r my.fitimzalı FIT üretir- Public key U-Boot DTB'sine gömülür;
CONFIG_FIT_SIGNATURE=yzorunlu mkimage -l my.fitimza doğrulamasını görsel olarak raporlar
03 NXP HAB — i.MX Secure Boot
NXP'nin HAB (High Assurance Boot) mekanizması, i.MX SoC'larda ROM bootrom seviyesinde imza doğrulaması sağlar; OTP fuse'lar ile cihaz kilitlenir.
HAB mimarisi
HAB, SoC ROM'una entegre edilmiş bir kriptografik kütüphanedir. ROM, SPL veya U-Boot binary'sini yüklemeden önce CSF (Command Sequence File) yapısını okur ve imzaları doğrular. Doğrulama başarısız olursa boot durur veya (Open device modunda) sadece uyarı verir.
SRK Key Pair (CST ile üretilir)
→ SRK Hash → OTP Fuse'a yazılır
→ CSF + imzalı binary → flash'a yazılır
→ ROM boot → HAB doğrulama → SPL çalışır
CST ile anahtar ve imza üretimi
# CST NXP web sitesinden indir: https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX_CST_TOOL
tar xf cst-3.3.2.tar.gz
cd cst-3.3.2/
# PKI ağacı oluştur (SRK + CSF + IMG key'ler)
cd keys/
./hab4_pki_tree.sh
# Do you want to use an existing CA key (y/n)?: n
# Enter key length in bits for PKI tree: 2048
# Enter PKI tree duration (years): 10
# How many Super Root Keys should be generated? 4
# SRK hash üret (OTP'ye yazılacak değer)
./srktool -h 4 -t SRK_1_2_3_4_table.bin \
-e SRK_1_2_3_4_fuse.bin \
-d sha256 \
-f 1 \
SRK1_sha256_2048_65537_v3_ca_crt.pem \
SRK2_sha256_2048_65537_v3_ca_crt.pem \
SRK3_sha256_2048_65537_v3_ca_crt.pem \
SRK4_sha256_2048_65537_v3_ca_crt.pem
# SRK fuse değerini görüntüle
hexdump -C SRK_1_2_3_4_fuse.bin
CSF dosyası ve imzalama
[Header]
Version = 4.2
Hash Algorithm = sha256
Engine = CAAM
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS
[Install SRK]
File = "../crts/SRK_1_2_3_4_table.bin"
Source index = 0
[Install CSFK]
File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
[Authenticate CSF]
[Install Key]
Verification index = 0
Target index = 2
File = "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
[Authenticate Data]
Verification index = 2
Blocks = 0x877ff400 0x000 0x00096000 "u-boot-dtb.imx"
# CSF binary üret
./cst/linux64/bin/cst -i u-boot-csf.txt -o u-boot-csf.bin
# U-Boot binary'sine CSF ekle
objcopy --gap-fill=0xff --pad-to=0x96000 u-boot-dtb.imx u-boot-padded.imx
cat u-boot-padded.imx u-boot-csf.bin > u-boot-signed.imx
hab_status ve fuse işlemleri
# HAB event log sorgula — U-Boot konsolunda
=> hab_status
# Secure boot disabled
# No HAB Events Found!
# (Tüm imzalar geçerliyse; hata varsa event gösterir)
# SRK hash fuse'larını yaz (GERİ ALINAMAZ!)
# fuse prog bankNo wordNo value
=> fuse prog 3 0 0xAABBCCDD # SRK_HASH[0]
=> fuse prog 3 1 0xEEFF0011 # SRK_HASH[1]
# ... (toplam 8 word)
# SEC_CONFIG[1] fuse'unu set et — cihazı KAPAT (Closed device)
# Bu işlemden sonra imzasız binary'ler çalışmaz!
=> fuse prog 0 6 0x00000002 # SEC_CONFIG[1] = Closed
OTP fuse programlama geri alınamaz. SEC_CONFIG[1] fuse'unu set etmeden önce imzalı binary'nin doğru çalıştığından kesinlikle emin olun. Yanlış SRK hash ile cihazı kapatırsanız cihaz kalıcı olarak brick olur.
Bu bölümde
- HAB: ROM seviyesinde imza doğrulama; CSF binary U-Boot'a eklenir
- CST ile SRK key pair üret; srktool ile fuse hash hesapla
hab_statusU-Boot konsolunda doğrulama durumunu raporlar- SEC_CONFIG fuse: Open → Closed geçişi geri alınamaz
04 TI AM335x Secure Boot
TI AM335x SoC'larda ROM bootrom, SPL'yi (MLO) X.509 sertifikasıyla doğrular; tisdk signing workflow bu süreci otomatikleştirir.
AM335x ROM boot süreci
AM335x ROM'u, MLO (SPL) binary'sini NAND, SD veya eMMC'den yüklerken Secure Boot etkinse X.509 sertifika doğrulaması gerçekleştirir. Sertifika binary'nin başına eklenir; ROM bu yapıyı otomatik tanır.
ROM → SRAM'a MLO yükle → X.509 header oku → RSA imzayı doğrula → SHAHash doğrula → SPL çalıştır
tiboot3.bin imzalama workflow
# TI SDK'dan k3-image-gen veya tisdk signing araçlarını edin
# https://git.ti.com/cgit/security-development-tools/core-secdev-k3/
git clone https://git.ti.com/git/security-development-tools/core-secdev-k3.git
cd core-secdev-k3/
# Anahtar çifti oluştur
openssl genrsa -out custMpk.pem 4096
# tiboot3.bin (SPL for AM625/AM64x) imzala
python3 scripts/gen_x509_cert.py \
-b tiboot3.bin \
-o tiboot3-signed.bin \
-k custMpk.pem \
-d sha512
# AM335x için MLO imzalama (eski yöntem)
python3 scripts/create-boot-certificate.py \
--key custMpk.pem \
--image u-boot-spl.bin \
--output MLO-signed
eFuse programlama (AM335x)
# Hedef üzerinde; mpk-hash OTP'ye yaz
# AM335x: EFUSE_SMA (0x44E10600) — software-locked after write
# devmem ile eFuse okuma (sadece programlanmamışsa)
devmem 0x44E10600 32 # EFUSE okuma
# TI ROM sboot_enable bit'ini set et
# Bu işlem için TI'ın eHSM servisini veya özel JTAG scriptini kullanın
# Detaylar: SPRUHF5 (AM335x TRM) Section 26.3 — Secure Boot
TI AM335x ve daha yeni K3 serisi SoC'larda (AM62x, AM64x) güvenli boot konfigürasyonu TRM (Technical Reference Manual) belgelerine ve TI'ın Secure Development Tools paketine göre yapılır. Her SoC serisi için signing format farklıdır — her zaman hedef SoC'un TRM'ini inceleyin.
Bu bölümde
- AM335x ROM, MLO binary'sini X.509 header + RSA imzayla doğrular
gen_x509_cert.pyveyacreate-boot-certificate.pyile imzalama- eFuse programlama; TI SPRUHF5 TRM Section 26.3 referans alın
- K3 serisi (AM62x, AM64x) farklı signing format — SoC TRM'ini takip edin
05 TPM 2.0 temelleri
TPM (Trusted Platform Module), kriptografik ölçümleri saklayan, anahtar üretip koruyan ve uzaktan doğrulama imzalayan donanım güvenlik modülüdür.
TPM 2.0 mimarisi
PCR extend işlemi
PCR register'larına değer yazmak extend işlemiyle olur — mevcut değerin üstüne yazılmaz, hash zinciriyle güncellenir: PCR_new = SHA256(PCR_old || measurement). Bu sayede ölçüm geçmişi değiştirilemez biçimde korunur.
# tpm2-tools kurulumu
sudo apt install tpm2-tools
# TPM2 cihazını listele
ls /dev/tpm*
# /dev/tpm0 /dev/tpmrm0
# Tüm PCR değerlerini oku
tpm2_pcrread
# sha256:
# 0 : 0x7D5F... (BIOS/ROM measurement)
# 1 : 0x8A2B... (BIOS config)
# 7 : 0x0000... (Secure Boot state)
# Belirli PCR'ları oku
tpm2_pcrread sha256:0,1,7
# Manuel PCR extend (test için)
tpm2_pcrextend 14:sha256=$(sha256sum myfile.bin | cut -d' ' -f1)
# Quote — PCR değerlerini TPM ile imzala (remote attestation)
# Önce bir Attestation Key oluştur
tpm2_createprimary -C e -c primary.ctx
tpm2_create -G ecc -u ak.pub -r ak.priv -C primary.ctx
tpm2_load -C primary.ctx -u ak.pub -r ak.priv -c ak.ctx
# PCR 0,1,7 quote'unu al
tpm2_quote \
-c ak.ctx \
-l sha256:0,1,7 \
-q $(openssl rand -hex 20) \
-m quote.msg \
-s quote.sig \
-o pcrs.out
TPM ile anahtar yönetimi
# PCR değerlerine bağlı (sealed) anahtar oluştur
# Sadece PCR 0 ve 7 belirli değerlerdeyken seal açılabilir
tpm2_createpolicy --policy-pcr -l sha256:0,7 -L pcr.policy
tpm2_create \
-C primary.ctx \
-i my-secret.bin \
-u sealed.pub \
-r sealed.priv \
-L pcr.policy
# Seal açma (PCR değerleri eşleşirse)
tpm2_load -C primary.ctx -u sealed.pub -r sealed.priv -c sealed.ctx
tpm2_unseal -c sealed.ctx --auth session:policy.session
Bu bölümde
- PCR = extend-only hash zinciri; değiştirilemez ölçüm geçmişi
tpm2_pcrread/tpm2_pcrextend/tpm2_quotetemel komutlar- Sealed key: belirli PCR değerlerine bağlı; sistem değiştirilirse açılmaz
/dev/tpm0: ham erişim;/dev/tpmrm0: resource manager aracılığıyla
06 Measured Boot ve IMA
Measured Boot, boot sürecinin her aşamasını TPM PCR'larına kaydederek sistem durumunun kriptografik kanıtını oluşturur; IMA bu ölçümü çalışma zamanına taşır.
Boot aşamalarının PCR dağılımı
| PCR | Ölçülen içerik | Kim extend eder |
|---|---|---|
| PCR 0 | SRTM (ROM code, BIOS/SBL) | ROM / donanım |
| PCR 1 | BIOS/EFI konfigürasyonu | Firmware |
| PCR 7 | Secure Boot state ve sertifikalar | UEFI / U-Boot |
| PCR 8–9 | GRUB / bootloader komutları | Bootloader |
| PCR 10 | IMA (Linux runtime ölçümler) | Linux kernel IMA |
| PCR 14 | Özel uygulama ölçümleri | Uygulama / systemd |
IMA — Integrity Measurement Architecture
IMA, Linux kernel'ının her çalıştırılan dosyayı (ve isteğe bağlı olarak okunan dosyaları) hash'leyerek PCR 10'a extend ettiği bir altyapıdır. Bu sayede çalışma zamanı bütünlüğü de TPM üzerinden kanıtlanabilir.
# Kernel config — IMA etkinleştirme
# CONFIG_IMA=y
# CONFIG_IMA_MEASURE_PCR_IDX=10
# CONFIG_IMA_APPRAISE=y
# CONFIG_INTEGRITY_SIGNATURE=y
# Kernel cmdline — IMA politikası
# ima_policy=tcb (trusted computing base: tüm exec + mmap ölç)
# IMA ölçüm log'unu görüntüle
cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements
# 10 sha256:... ima-ng sha256:... /usr/sbin/sshd
# 10 sha256:... ima-ng sha256:... /lib/x86_64-linux-gnu/libpam.so.0
# TPM PCR 10 değerini oku
tpm2_pcrread sha256:10
# Bu değer IMA log'unun tüm extend işlemlerinin sonucudur
# IMA appraise: dosya imzalarını zorla
# Kernel cmdline: ima_appraise=enforce
# Her çalıştırılabilir dosyanın xattr'ında IMA imzası olmalı:
evmctl ima_sign --key /etc/keys/signing_key.pem /usr/bin/myapp
Kernel security sysfs
# Mevcut TPM cihazını listele
ls /sys/kernel/security/tpm0/
# ascii_bios_measurements
# binary_bios_measurements
# IMA politika dosyası
cat /sys/kernel/security/integrity/ima/policy
# securityfs mount edilmemişse
mount -t securityfs securityfs /sys/kernel/security
IMA log'u büyük sistemlerde hızla büyür. Üretim sistemlerinde IMA politikasını yalnızca kritik binary'leri (init, sshd, web server) kapsayacak şekilde daraltın. Tüm dosya sistemi için IMA appraise I/O performansını etkileyebilir.
Bu bölümde
- PCR dağılımı: 0=ROM, 7=Secure Boot, 10=IMA çalışma zamanı
- IMA her çalıştırılan dosyayı hash'leyerek PCR 10'a extend eder
/sys/kernel/security/integrity/ima/ascii_runtime_measurementslog dosyası- IMA appraise:
evmctl ima_signile dosyalara xattr imza eklenir
07 OP-TEE ve TrustZone
ARM TrustZone, işlemciyi Normal World ve Secure World olarak ikiye ayırır; OP-TEE bu Secure World'de çalışan açık kaynaklı TEE implementasyonudur.
TrustZone mimarisi
Normal World (REE) Secure World (TEE)
────────────────────── ──────────────────────
Linux kernel OP-TEE OS
User applications Trusted Applications (TA)
tee-supplicant (user daemon) ←SMC→ OP-TEE core
Secure storage
Crypto operations
OP-TEE build ve entegrasyon
# OP-TEE OS deposu
git clone https://github.com/OP-TEE/optee_os.git
cd optee_os/
# Raspberry Pi 3 için build (CFG_ARM64_core=y ile 64-bit)
make PLATFORM=rpi3 \
CFG_ARM64_core=y \
CROSS_COMPILE64=aarch64-linux-gnu- \
CROSS_COMPILE=arm-linux-gnueabihf-
# AM335x (BeagleBone Black)
make PLATFORM=ti-am43xx \
CROSS_COMPILE=arm-linux-gnueabihf-
# Çıktı: tee-pager_v2.bin, tee.elf
ls out/arm-plat-rpi3/core/
# tee.elf tee-pager_v2.bin tee-header_v2.bin tee-pageable_v2.bin
Trusted Application geliştirme
#include <tee_internal_api.h>
#include <tee_internal_api_extensions.h>
/* TA UUID — uuidgen ile benzersiz üret */
#define TA_MY_UUID { 0x8aaaf200, 0x2450, 0x11e4, \
{ 0xab, 0xe2, 0x00, 0x02, 0xa5, 0xd5, 0xc5, 0x1b } }
TEE_Result TA_CreateEntryPoint(void) {
return TEE_SUCCESS;
}
void TA_DestroyEntryPoint(void) { }
TEE_Result TA_OpenSessionEntryPoint(uint32_t paramTypes,
TEE_Param params[4],
void **sessionCtx) {
return TEE_SUCCESS;
}
void TA_CloseSessionEntryPoint(void *sessionCtx) { }
TEE_Result TA_InvokeCommandEntryPoint(void *sessionCtx,
uint32_t commandID,
uint32_t paramTypes,
TEE_Param params[4]) {
switch (commandID) {
case 0: /* Örnek: AES şifreleme */
/* ... TEE_AllocateOperation, TEE_CipherDoFinal ... */
return TEE_SUCCESS;
default:
return TEE_ERROR_NOT_SUPPORTED;
}
}
tee-supplicant ve Linux sürücüsü
# Kernel config
# CONFIG_TEE=y
# CONFIG_OPTEE=y
# tee-supplicant daemon'ı başlat (systemd ile)
systemctl start tee-supplicant
# TEE cihaz dosyası
ls /dev/tee*
# /dev/tee0 /dev/teepriv0
# optee_client ile CA test uygulaması çalıştır
xtest # OP-TEE test suite
# Secure storage konumu (tee-supplicant'ın yönettiği)
ls /data/tee/
# dirf.db dirf.db.bak (şifrelenmiş TA storage)
Bu bölümde
- TrustZone: Normal World (Linux) / Secure World (OP-TEE) donanım izolasyonu
- SMC ile Normal World → Secure World geçişi; tee-supplicant aracılık eder
- TA: Secure World'de çalışan imzalı mini uygulama; TEE Internal API ile yazılır
- Secure Storage: OP-TEE şifreli kalıcı depolama; private key ve credential'lar için
08 dm-verity ile rootfs bütünlüğü
dm-verity, Linux Device Mapper katmanında rootfs'in her bloğunu okurken hash doğrulaması yapar; değiştirilmiş bir blok I/O hatasıyla reddedilir.
dm-verity çalışma prensibi
dm-verity, Merkle hash tree kullanır. Her 4 KB veri bloğu için bir hash hesaplanır; bu hash'ler bir üst katmanda gruplanarak hash'lenir; ağaç tepesindeki root hash kernel cmdline'a veya imzalı bir yapıya gömülür. Root hash değişemeyeceğinden, dosya sistemi üzerindeki herhangi bir değişiklik anında tespit edilir.
root hash (kernel cmdline / signed) → hash tree → data blocks (rootfs)
veritysetup ile dm-verity image üretme
# cryptsetup/veritysetup kurulumu
sudo apt install cryptsetup
# squashfs rootfs oluştur (read-only, dm-verity ile uyumlu)
mksquashfs rootfs/ rootfs.squashfs -comp lz4 -noappend
# dm-verity hash tree oluştur
# --data-block-size: 4096 (sayfa boyutu)
# --hash-block-size: 4096
# Çıktı: rootfs.hash (hash tree), root hash değeri stdout'a
veritysetup format \
rootfs.squashfs \
rootfs.hash \
--data-block-size=4096 \
--hash-block-size=4096 \
--hash=sha256
# Root hash: 7d5f8a...c3b2 (bu değeri kernel cmdline'a koy)
# dm-verity cihazı aç (çalışan sistemde test)
veritysetup open \
rootfs.squashfs vroot \
rootfs.hash \
7d5f8a...c3b2 # root hash buraya
# Doğrulanmış rootfs'i mount et
mount -t squashfs -o ro /dev/mapper/vroot /mnt
Kernel cmdline ile dm-verity rootfs
# U-Boot environment
setenv bootargs "root=/dev/dm-0 \
dm-mod.create=\"vroot,,0,ro, \
0 $(rootfssize_sectors) verity 1 \
/dev/mmcblk0p2 /dev/mmcblk0p3 \
4096 4096 $(rootfs_blocks) 1 sha256 \
7d5f8a...c3b2 salt\" \
rootfstype=squashfs rootflags=ro"
# Hash tree doğrulamasını aç (çalışan sistemde)
veritysetup verify rootfs.squashfs rootfs.hash 7d5f8a...c3b2
# Verification succeeded.
# Kernel dm-verity log (dmesg)
dmesg | grep -i "verity"
# [ 3.456789] device-mapper: verity: sha256 using implementation "sha256-generic"
# [ 3.456900] device-mapper: verity: 253:0: Root hash: 7d5f...
dm-verity rootfs salt-okunur olmalıdır — herhangi bir yazma girişimi doğrulama hatasına ve I/O reddiyle sonuçlanır. Yazılabilir veri için ayrı bir partition (UBI+UBIFS veya ext4) kullanın; rootfs'in üstüne overlayfs ile yazılabilir katman ekleyebilirsiniz.
Bu bölümde
- dm-verity Merkle hash tree ile her veri bloğunu okuma anında doğrular
veritysetup format rootfs.squashfs rootfs.hashhash tree üretir- Root hash kernel cmdline veya imzalı image'a gömülür
- dm-verity rootfs salt-okunur; yazılabilir veri için ayrı partition kullanın
09 Pratik: Raspberry Pi Secure Boot
Raspberry Pi 4/5, OTP fuse ile imzalı boot loader zorunluluğu sağlar; HAB olmayan platformlarda U-Boot FIT imzalama zinciri ile benzer güvence elde edilir.
Raspberry Pi 4 OTP Secure Boot
Raspberry Pi 4, BCM2711 SoC'undaki OTP'ye programlanan bir RSA public key hash ile boot loader doğrulamasını destekler. Bu özellik Raspberry Pi Foundation tarafından 2021 sonrasında duyurulmuş olup üretim kullanımı için resmi araçlarla yapılandırılır.
# rpi-eeprom deposu (raspberry pi secure boot araçları)
git clone https://github.com/raspberrypi/usbboot.git
cd usbboot/secure-boot-example/
# RSA-2048 anahtar üret
openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout -out public.pem
# Public key hash hesapla (OTP'ye yazılacak)
python3 ../tools/rpi-eeprom-digest \
-i public.pem \
-o public_key_hash.bin
# rpi-eeprom-config ile OTP'ye yaz (device'ı Pi'ye bağlayın)
sudo rpi-eeprom-config --otp-public-key public.pem \
--apply /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2024-10-22.bin
Boot loader ve kernel imzalama
# rpi-eeprom-digest ile bootloader imzala
python3 usbboot/tools/rpi-eeprom-digest \
-i pieeprom.bin \
-o pieeprom.signed.bin \
-k private.pem
# Raspberry Pi üzerinde durum sorgula
vcgencmd bootloader_config | grep -i "secure"
# SECURE_BOOT_REQUIRED=0 (0=disabled, 1=enabled)
# OTP durum okuma
vcgencmd otp_dump | grep "66:"
# 66:00000000 (secure boot OTP word)
HAB'sız platformlarda U-Boot FIT ile güven zinciri
HAB gibi donanım destekli ROM doğrulaması olmayan platformlarda (Pi 3 gibi), güven zinciri U-Boot FIT imzalamasıyla sağlanabilir. Bu yaklaşım ROM seviyesinde değil U-Boot seviyesinde koruma sağlar — dolayısıyla U-Boot binary'sinin kendisi değiştirilebilir. Gerçek güvenlik için OTP mekanizması zorunludur.
# 1. Anahtar üret
mkdir -p keys/
openssl genrsa -out keys/dev.key 2048
openssl req -new -x509 -key keys/dev.key \
-out keys/dev.crt -days 3650 -subj "/CN=Pi Boot Key"
# 2. U-Boot build (Pi için)
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
make rpi_4_defconfig
# menuconfig: FIT_SIGNATURE=y, RSA=y, CONFIG_OF_CONTROL=y
make -j$(nproc)
# 3. FIT image oluştur ve imzala (public key u-boot.dtb'ye gömülür)
mkimage -f pi4.its -k keys/ -K arch/arm64/dts/broadcom/bcm2711-rpi-4-b.dtb \
-r pi4-signed.fit
# 4. Kopyala
cp u-boot.bin /boot/
cp pi4-signed.fit /boot/
# 5. config.txt'de U-Boot'u bootloader olarak ayarla
# kernel=u-boot.bin
# arm_64bit=1
# enable_uart=1
Raspberry Pi'nin kendi ROM'u kapalı kaynak ve imzasız binary'lere izin verir. Gerçek üretim güvenliği için Raspberry Pi 4/5'in OTP Secure Boot özelliği veya benzer donanım kilitlemesi (fuse, eFuse) gereklidir. Sadece U-Boot FIT imzalama, U-Boot binary'sinin kendisini korumaz.
Bu bölümde
- Pi 4 OTP Secure Boot: RSA-2048 public key hash OTP'ye yazılır; boot loader imzalanır
rpi-eeprom-digestile imzalama;vcgencmd otp_dumpile durum kontrolü- HAB'sız platformlarda U-Boot FIT imzalama U-Boot sonrası zinciri korur
- Tam güvenlik için OTP/fuse mekanizması zorunlu; sadece FIT imzalama yeterli değil