Belajar IoT Engineer - Device Identity & PKI

#Pendahuluan

Di episode 7 kita membuat sertifikat perangkat lewat CLI, dan di episode 11 kita tahu flash bisa dibaca. Sekarang kita rangkai keduanya jadi jawaban untuk satu pertanyaan krusial: bagaimana memberi identitas yang tidak bisa dipalsukan kepada ribuan perangkat, dan mengelola identitas itu sepanjang umur perangkat?

Mengapa topik ini inti keamanan IoT? Karena semua kontrol akses — siapa boleh publish, siapa boleh update, data siapa ini — bergantung pada identitas. Identitas yang bisa dipalsukan berarti kontrol akses itu ilusi. PKI dan secure element adalah cara dunia nyata menyelesaikannya.

#Dasar PKI untuk IoT

PKI (Public Key Infrastructure) adalah sistem yang mengelola sertifikat dan kunci. Untuk IoT, alurnya sederhana:

Siklus hidup sertifikat perangkat

CA menerbitkan → device install → device connect (mTLS)
    → verifikasi identitas → expiring → renew/revoke

Komponen kunci:

Komponen	Peran
CA (Certificate Authority)	Penerbit sertifikat terpercaya
Device certificate	Identitas perangkat — diikat ke public key perangkat
Private key	Rahasia perangkat — tidak pernah keluar dari perangkat
Revocation	Mencabut sertifikat perangkat yang tidak lagi dipercaya

Konsep terpenting: private key dan sertifikat terpisah. Sertifikat itu publik (boleh disebar), private key rahasia. Keamanan identitas sepenuhnya bergantung pada private key yang tidak bisa dicuri.

#Secure Element dan HSM

Masalahnya: flash ESP32 bisa dibaca dengan alat forensik. Solusinya adalah secure element — chip kecil khusus yang menyimpan kunci dan melakukan kriptografi di dalam chip, tanpa pernah mengekspos kunci.

Secure element di perangkat

ESP32 ──I2C──> ATECC608 (secure element)
                 ├── private key (tidak pernah keluar)
                 └── tanda tangan/cryptography di dalam chip

Alat	Fungsi	Dimana
Secure element (ATECC608, SE050)	Simpan kunci + kriptografi per device	Di perangkat IoT
HSM	Simpan kunci + kriptografi untuk CA/cloud	Di pusat data

Bahkan jika penyerang memegang perangkat secara fisik, private key di secure element tidak bisa diekstrak. Mencoba membaca = chip mengunci diri. Ini mengubah "perangkat dicuri = kunci bocor" menjadi "perangkat dicuri = perangkat saja yang hilang".

#Siklus Hidup Sertifikat

Sertifikat tidak abadi. Kelola seluruh siklusnya:

Fase	Tindakan
Issue	CA menerbitkan sertifikat di pabrik / saat join
Active	Perangkat memakainya untuk mTLS
Renew	Ganti sebelum kedaluwarsa (biasanya 1–5 tahun)
Revoke	Cabut saat perangkat hilang, dihentikan, atau mencurigakan
Expire	Perangkat tidak bisa connect — pastikan renew terjadwal

Perangkat yang sertifikatnya kedaluwarsa dan tidak bisa renew akan terkunci dari sistem — ini operasi yang bisa melumpuhkan fleet jika tidak dijadwalkan. Monitoring masa berlaku sertifikat adalah bagian dari fleet management (episode 9).

#Zero-Touch Provisioning

Memasang sertifikat ke ribuan perangkat satu per satu tidak mungkin. Zero-touch provisioning (ZTP) membuat perangkat mengamankan identitasnya sendiri:

Alur zero-touch provisioning (JITP di AWS)

Pabrik: tanam sertifikat produksi + kunci di secure element
   → perangkat dikirim ke lapangan
   → perangkat connect pertama kali ke AWS IoT
   → AWS verifikasi sertifikat produksi (CA terpercaya)
   → AWS mendaftarkan perangkat secara otomatis (auto-register)
   → perangkat aktif, siap dipakai

#Just-in-Time Provisioning (JITP)

Di AWS IoT, JITP adalah contoh nyata ZTP:

Daftarkan CA produksi ke AWS (sekali saja)

aws iot register-ca-certificate --ca-certificate-file ca.pem \
  --set-as-active --allow-auto-registration

Setelah CA terdaftar dengan auto-registration, perangkat apa pun yang datang dengan sertifikat dari CA tersebut otomatis didaftarkan — tanpa campur tangan manual. Pabrik cukup menanam sertifikat ke perangkat, dan cloud "mengenali" mereka saat connect pertama.

Important

Auto-registration hanya aman jika sertifikat produksi tidak pernah bocor. Jika CA produksi bocor, seluruh fleet bisa didaftarkan oleh penyerang. Praktek industri: CA yang membuat sertifikat perangkat berbeda dari CA yang mengotentikasi — dan CA akar (root) disimpan offline.

#Praktik: Membuat Sertifikat Perangkat

Alur manual yang sudah kita kenal dari episode 7 — sekarang dengan perspektif PKI:

Buat CSR perangkat di pabrik

openssl req -new -newkey rsa:2048 -nodes \
  -keyout device.key -out device.csr \
  -subj "/CN=device-00-01"

CA menandatangani CSR (di HSM/produksi)

openssl x509 -req -in device.csr \
  -CA ca.pem -CAkey ca.key -CAcreateserial \
  -days 1825 -out device.crt

Perhatikan: device.key dibuat di pabrik dan tidak pernah meninggalkan perangkat/secure element; yang dikirim ke CA hanya device.csr (permintaan sertifikat, tanpa kunci).

#Kesalahan Umum

Private key disimpan di flash biasa — pencurian fisik = kunci bocor; pakai secure element.
Satu sertifikat untuk semua perangkat — kompromi satu perangkat = seluruh fleet; identitas harus per-device.
Sertifikat tidak pernah diperbarui — fleet terkunci mendadak saat expire massal.
Root CA online — jika root CA diretas, semua bisa dipalsukan; simpan offline.
Auto-registration tanpa proteksi CA — penyerang bisa mendaftarkan perangkat palsu.
Revocation tidak digunakan — perangkat yang dihentikan tetap bisa connect.

#Penutup

Inti yang harus dibawa pulang:

PKI = sistem identitas perangkat: CA menerbitkan, perangkat memegang sertifikat + private key.
Private key tidak pernah keluar dari perangkat; sertifikat boleh publik.
Secure element melindungi kunci dari pencurian fisik; HSM melindungi kunci CA.
Kelola siklus hidup sertifikat: issue → active → renew → revoke → expire.
Zero-touch provisioning (JITP): CA terdaftar → perangkat auto-register saat connect pertama.
Simpan root CA offline; identitas harus per-device, bukan global.

Di episode 20 selanjutnya, kita akan melihat sisi hukum dan etika: privacy & regulatory IoT — GDPR dan peraturan data di Indonesia, minimalisasi data, persetujuan pengguna, serta praktik membuat compliance checklist untuk produk IoT kalian. Karena kepatuhan bukan biaya — ini fitur!