Belajar Embedded Engineer - Embedded Security

#Pendahuluan

Di episode 12 perangkat kalian terhubung ke dunia; episode 17 memberi mereka OTA yang aman. Episode ini membahas konsekuensinya: perangkat terhubung adalah permukaan serangan, dan perangkat yang kalian pegang adalah perangkat yang bisa dibongkar, dipelajari, dan dibajak oleh siapa pun di lapangan.

Berbeda dengan server di data center, perangkat embedded tidak punya tembok fisik. Penyerang bisa membeli perangkat kalian di toko, membuka kasingnya, menyolder probe ke chip, dan membaca firmware dengan alat $100. Episode ini membangun kemampuan berpikir seperti penyerang — dan merancang pertahanan yang realistis untuk resource yang terbatas.

#Threat Model: Dari Mana Ancaman Datang?

Sebelum menambah satu baris keamanan, jawab dulu: siapa penyerang kita, dan apa yang mereka mau? Untuk embedded, model ancaman khas:

Setiap motif membutuhkan pertahanan yang berbeda. Membangun hardware security module untuk melindungi produk senilai $50 dari kompetitor adalah pemborosan; mengabaikan autentikasi perangkat yang mengendalikan kunci pintu adalah kelalaian. Prioritaskan sesuai nilai aset dan akses penyerang.

#Kriptografi di Perangkat Terbatas

Tidak semua kriptografi diciptakan sama — dan di MCU, biayanya nyata dalam clock dan RAM:

Aturan praktis MCU:

1. AES untuk enkripsi data, ECDSA untuk autentikasi/verifikasi firmware.
2. Gunakan hardware crypto accelerator bila ada (STM32, ESP32 punya) — lebih cepat, lebih hemat daya, dan lebih tahan side-channel daripada implementasi software.
3. Jangan membuat kriptografi sendiri — gabungkan primitif standar dengan mode aman (AES-GCM, ECDSA), bukan "algoritma unik" buatan tim.

Mengelola kunci lebih penting daripada memilih algoritma. Kunci di flash biasa bisa dibaca dengan firmware dump; kunci di secure element / TPM hampir mustahil dibaca — trade-off biaya vs keamanan yang harus diambil per produk.

#Melindungi Firmware dari Pembacaan

Ini lapisan pertahanan yang sering diremehkan: mengunci akses baca ke flash. Jika flash bisa dibaca, seluruh firmware — termasuk kunci yang tertanam — bisa diekstrak dengan st-flash read.

Langkah hardening pada tingkat chip:

1. Read-out protection (RDP) — set level RDP di STM32 (0/1/2). Level 2 tidak bisa dibuka sama sekali.
2. JTAG/SWD lock — nonaktifkan debug port setelah production programming.
3. Hapus kunci dari binary — kunci sejati ada di secure element atau provisioning server, bukan hardcode.
4. Obfuscation secukupnya — menghalangi "santai", bukan lawan yang serius.

#Side-Channel & Serangan Fisik

Keamanan embedded berhadapan dengan penyerang yang memegang hardware — dan hardware berbicara. Serangan kelas ini membaca sampingan bukan isinya:

Pertahanan realistis untuk kebanyakan produk: gunakan crypto library yang sudah diaudit (MbedTLS, TinyCrypt), pakai hardware crypto accelerator, dan aktifkan proteksi chip. Membangun pertahanan anti-DPA sendiri di luar kompetensi kebanyakan tim — serahkan ke chip dengan secure element bila benar-benar dibutuhkan.

#Hardening Menyeluruh: Checklist

Menyatukan semuanya, checklist hardening firmware produksi:

1. Secure boot + anti-rollback — dari episode 17.
2. OTA terotentikasi — signature + TLS, dari episode 17.
3. Kunci di secure element, bukan hardcode di binary.
4. RDP/SWD lock di akhir produksi.
5. Input validation di semua parser (protokol, config, OTA payload) — buffer overflow adalah gerbang masuk utama.
6. Debug/info ditekan di build release — log verbose hanya untuk debug build.
7. Monotonic counter / tamper detection bila asetnya bernilai.
8. Bahan audit: versi firmware + hash tercatat (episode 16).

#Praktik: Hardening Firmware Pertama

1. Audit firmware kalian dengan daftar checklist di atas — catat apa yang sudah dan belum ada.
2. Aktifkan RDP level 1 di board, lalu coba st-flash read — amati gagalnya.
3. Implementasikan verifikasi signature OTA (lanjutkan episode 17) jika belum.
4. Tempatkan secret di flash + konfigurasi terpisah, bukan hardcode.
5. Tulis threat model singkat (2 halaman) untuk produk imajiner kalian — latihan berpikir seperti penyerang.

#Common Pitfalls

1. Hardcode kunci di binary — ekstrak dengan satu perintah read flash.
2. Mengunci chip sebelum proses OTA mapan — perangkat tak bisa di-update.
3. Kriptografi buatan sendiri — "lebih aman" justru sebaliknya.
4. Tanpa input validation — parser yang naif adalah pintu masuk utama.
5. Keamanan tanpa threat model — melindungi hal yang salah dengan biaya yang salah.

#Penutup

Inti yang harus dibawa pulang:

• Mulai dari threat model: siapa penyerang, apa asetnya, berapa biaya serangannya.
• Pilih kriptografi sesuai resource: AES untuk data, ECDSA untuk autentikasi, pakai HW accelerator.
• Lindungi firmware dari pembacaan: RDP, SWD lock, kunci di secure element.
• Pahami side-channel attack dan ketahui kapan pertahanannya masuk akal.
• Keamanan adalah lapisan yang seimbang dengan biaya — bukan kesempurnaan yang mustahil.

Di episode 19 selanjutnya kita masuk ke dunia di mana kesalahan berarti nyawa: safety & reliability (MISRA) — menulis C yang aman, mendesain fail-safe, dan menerapkan standar fungsional safety. Ini adalah tingkat kualitas tertinggi yang pernah diminta dari seorang engineer. Sampai jumpa di episode 19!