Mengamankan jalur update firmware: signed update dengan rantai kepercayaan, manifest dan verifikasi sebelum boot, anti-rollback untuk mencegah downgrade attack, integritas end-to-end, serta praktik menyusun pipeline secure update dari build hingga commit di perangkat.

Setelah di episode 18 firmware kita di-hardening dan di episode 13 kita merancang pipeline OTA, pada episode ini kita menggabungkan keduanya menjadi Secure OTA. Karena jika update bisa diserang, semua proteksi lain runtuh: attacker yang bisa memasang firmware-nya sendiri akan melewati secure boot, enkripsi, dan anti-tamper sekaligus.
Mengapa ini penting? Update adalah pintu paling berbahaya: ia membawa kode baru ke perangkat, dan melalui pintu itulah malware paling sering masuk. Menandatangani update, memverifikasinya sebelum boot, dan mencegah downgrade adalah tiga pilar yang membuat perangkat hanya bisa diperbarui oleh kalian — bukan oleh penyerang.
Update firmware tidak boleh dipercaya berdasarkan asal "dari server" saja — koneksi bisa dibajak. Solusinya: tanda tangan kriptografis.
Alur lengkap:
{
"product": "lamp-v2",
"version": "1.4.0",
"build_id": "20260816-042",
"image_sha256": "8f3a...c1",
"image_size": 102400,
"signature": "MEUCIQC...",
"min_supported": "1.2.0"
}Signature hanya berguna jika diverifikasi sebelum kode dieksekusi — bukan "nanti". Urutan wajib:
1. Unduh image chunk-by-chunk sambil menghitung hash
2. Setelah lengkap: cek hash == manifest.hash
3. Cek signature atas (hash || metadata)
4. Cek versi > versi sekarang (anti-downgrade)
5. Tulis ke slot pasif (bukan slot aktif!)
6. Reboot dari slot pasif; sukses -> commit; gagal -> rollbackKesalahan klasik: mem-boot image sebelum verifikasi selesai, atau memindahkan ke slot aktif saat masih "pending". Setiap langkah adalah gate; tidak boleh ada yang dilewati.
Attacker yang punya firmware lama yang sudah bocor (mengandung kunci/old vuln) akan mencoba downgrade ke versi itu. Perangkat harus menolak versi yang lebih lama dari minimum:
Version counter : disimpan di flash/NVS terproteksi, hanya bisa naik
Secure version : eFuse/OTP (satu arah, tidak bisa diputar balik)
Aturan : image dengan versi < counter DITOLAK
Efektivitas : downgrade attack gagal walau attacker punya image lamaKombinasi umum: version counter di NVS (mudah, bisa reset oleh firmware terbaru) + efuse untuk titik yang tidak bisa diputar (misal setelah major security fix). Pilih level sesuai risiko produk.
Warning
"Signed tapi diverifikasi setelah boot" sama artinya dengan tidak aman — code signing yang benar memverifikasi sebelum eksekusi. Juga jangan pernah menaruh private key signing di CI runner atau repo: satu kali bocor, attacker menandatangani image apa pun dan seluruh rantai runtuh.
Skema lengkap yang bisa kalian adopsi:
CI : build -> test -> sign (HSM) -> publish manifest
Update server : validasi, rate-limit, serving lewat CDN (TLS)
Perangkat : HTTPS + mTLS -> unduh -> hash+signature -> tulis slot
Rollout : 5% -> 25% -> 100%, auto-pause jika error rate naik
Monitoring : versi tersebar, success rate, brick rate
Rollback : auto bila boot gagal / timeout / versi tak sehatPerhatikan monitoring sebagai fitur keamanan: kenaikan brick rate mendadak adalah sinyal image bermasalah — atau serangan — dan harus menghentikan rollout secara otomatis.
Inti yang harus dibawa pulang:
Di episode 20 selanjutnya kita menulis firmware yang bisa disertifikasi: Safety & MISRA — MISRA C, functional safety (IEC 61508/ISO 26262), dan proses review yang membuat firmware layak untuk domain paling berisiko. Kode kalian akan layak masuk pesawat dan rumah sakit!