Belajar IoT Engineer - IoT Security Fundamentals

#Pendahuluan

Di episode 5 kita sempat mencatat bahwa payload MQTT kita tidak terenkripsi. Episode ini menuntaskan catatan itu: keamanan bukan fitur tambahan, tapi fondasi yang harus dipikirkan sejak episode 2 — dan kini kita bahas dari sisi perangkat.

Mengapa keamanan IoT sangat serius? Karena perangkat IoT menyebar di luar kontrol: sensor di gudang, kamera di rumah, meteran di jalan. Botnet seperti Mirai telah membuktikan — puluhan ribu perangkat yang tidak diamankan bisa direkrut jadi senjata serangan DDoS raksasa. Satu perangkat yang lemah bisa menjadi jalan masuk ke seluruh jaringan.

#Ancaman yang Membidik Perangkat

Ancaman	Cara Kerja	Dampak
Spoofing	Memalsukan identitas perangkat	Data palsu, alarm palsu
Tampering	Mengubah firmware atau data	Perilaku perangkat dikendalikan
Eavesdropping	Menyadap komunikasi tanpa enkripsi	Data pribadi bocor
Replay	Mengulang pesan yang sah	Command lama dieksekusi ulang
Physical	Mengakses perangkat secara fisik	Kunci ekstraksi, flash ulang

Keamanan IoT dimulai dari asumsi penting: perangkat bisa diakses secara fisik dan jaringan tidak bisa dipercaya. Semua pengamanan harus bertahan walau penyerang memegang perangkat atau menyadap komunikasi.

#Empat Pilar Keamanan Perangkat

#1. Secure Boot

Secure boot memastikan perangkat hanya menjalankan firmware yang sah. Prosesnya: bootloader memverifikasi tanda tangan digital firmware menggunakan kunci yang tertanam (root of trust) sebelum dieksekusi. Jika firmware rusak atau diubah, perangkat menolak boot.

Alur secure boot

Bootloader → verifikasi signature firmware dengan root key
    → cocok: jalankan firmware / tidak cocok: tolak boot

Tanpa secure boot, penyerang yang bisa menulis flash akan menginstall firmware jahat yang mengubah perangkat jadi zombie.

#2. TLS: Enkripsi Komunikasi

Semua komunikasi IoT harus melewati TLS — MQTT over TLS (port 8883), HTTPS untuk API, dan DTLS untuk UDP. Di episode 7 kita sudah menerapkan TLS ke AWS IoT. Kuncinya:

Aspek	Praktik Benar
Verifikasi sertifikat	Selalu verifikasi CA server — jangan `setInsecure()`
Versi TLS	TLS 1.2/1.3; tolak versi lama
Cipher	Hanya cipher kuat; hindari cipher lama yang lemah
Certificate pinning	Opsional untuk melawan CA yang dikompromikan

Kesalahan paling umum di firmware: menonaktifkan verifikasi sertifikat ("biar cepat") — ini sama dengan menandatangani blank cheque: siapapun bisa jadi "cloud" untuk perangkat kalian.

#3. Identitas Perangkat

Setiap perangkat butuh identitas unik yang tidak bisa dipalsukan — bukan MAC address (bisa diubah), tapi sertifikat atau kunci yang disimpan aman. Di episode 19 kita bahas mendalam soal PKI; di episode ini yang penting: identitas perangkat = credential per-device, jangan berbagi satu kunci untuk semua perangkat.

Identitas per device (bukan global)

Perangkat A → sertifikat A
Perangkat B → sertifikat B
X → tidak punya sertifikat → ditolak platform

Jika satu kunci dipakai semua perangkat, pencurian satu perangkat mengkompromikan seluruh fleet.

#4. Keamanan Update

Di episode 9 kita bahas OTA; sekarang dari sisi keamanan: update harus ditandatangani dan diverifikasi di perangkat.

Verifikasi signature firmware sebelum update

#include <mbedtls/md.h>
 
bool verifyFirmwareSignature(const uint8_t *fw, size_t fwLen,
                             const uint8_t *sig, size_t sigLen) {
    // 1. hash firmware yang diunduh
    // 2. verifikasi signature dengan public key yang tertanam di bootloader
    // 3. return true hanya jika valid
}

Selain verifikasi, jaga juga: server update aman (HTTPS + auth), tidak ada rollback ke versi lama yang rentan (anti-downgrade), dan update di-push bertahap (episode 9).

#Praktik: Hardening Checklist Perangkat

Terapkan checklist berikut ke firmware ESP32 kalian:

#	Item	Status
1	MQTT memakai TLS 8883, bukan 1883 plaintext	☐
2	Verifikasi sertifikat server aktif (no `setInsecure`)	☐
3	Kredensial tidak hardcode — dari secure storage/EEPROM terenkripsi	☐
4	Firmware ditandatangani & diverifikasi sebelum eksekusi	☐
5	Identitas per-device, bukan satu kunci global	☐
6	Topik dan policy platform dibatasi minimal (episode 7)	☐
7	Port layanan debug (serial, telnet) dimatikan di produksi	☐
8	Update firmware anti-downgrade	☐

Periksa juga komunikasi lokal: jangan tinggalkan endpoint tanpa otentikasi yang bisa dipakai penyerang untuk mengontrol perangkat lewat jaringan lokal.

Warning

ESP32 menyimpan kredensial di flash dengan enkripsi parsial, tapi flash masih bisa dibaca dengan alat forensik. Untuk produk dengan risiko tinggi, gunakan chip secure element (ATECC608, episode 19) — kunci privat tidak pernah keluar dari chip, sehingga mencuri perangkat pun tidak memberi penyerang akses ke kunci.

#Kesalahan Umum

setInsecure() / tidak verifikasi sertifikat — pintu masuk MITM terbesar di firmware.
Satu kunci untuk semua perangkat — kompromi satu perangkat = kompromi semua.
Mengirim kredensial WiFi/broker dalam plaintext — siapa pun dengan packet sniffer bisa mencurinya.
Update tanpa signature — server OTA yang diretas = kendali penuh atas perangkat.
Serial/console aktif di produksi — akses fisik + console = root tanpa password.
Mengabaikan update keamanan — perangkat lama yang tidak pernah di-update jadi target botnet.

#Penutup

Inti yang harus dibawa pulang:

Ancaman IoT: spoofing, tampering, eavesdropping, replay, dan akses fisik.
Empat pilar: secure boot, TLS, identitas perangkat, dan keamanan update.
TLS wajib dengan verifikasi sertifikat — jangan pernah setInsecure().
Identitas per-device; jangan berbagi kunci global.
Update harus ditandatangani + diverifikasi + anti-downgrade.
Terapkan hardening checklist sebelum perangkat meninggalkan lab.

Di episode 12 selanjutnya, kita akan mengubah telemetry menjadi wawasan: time series & data analytics IoT — bagaimana InfluxDB menyimpan data berstempel waktu, deteksi anomali, dan membangun dashboard, plus praktik menganalisis data dari perangkat kalian. Data mulai "berbicara"!