Pendahuluan

Sistem embedded ada di sekitar kita, sering bekerja tanpa terlihat. Sensor suhu yang mengirim data ke cloud, ECU pada kendaraan, robot gudang, kamera IP, smart meter, mesin industri, printer, router rumah, perangkat medis portabel, dan pengendali motor listrik semuanya adalah komputer—tetapi bukan komputer dalam bentuk laptop atau server umum. Mereka adalah komputer yang ditanamkan ke dalam produk, diberi tugas khusus, terhubung ke dunia fisis, dan sering diharapkan bekerja selama bertahun-tahun.

Buku ini membahas keamanan siber untuk sistem seperti itu.

Kita akan belajar bukan hanya “apa itu secure boot” atau “apa itu buffer overflow”, tetapi mengapa konsep-konsep itu muncul secara alami dari cara komputer kecil mengeksekusi instruksi, menyimpan data, menerima input, mempercayai firmware, berkomunikasi melalui bus, dan berinteraksi dengan lingkungan. Tujuan buku ini adalah membangun pemahaman yang dapat digunakan untuk merancang, menganalisis, menguji, dan memperbaiki sistem embedded secara bertanggung jawab.

Mengapa keamanan sistem embedded berbeda?

Secara sederhana, sistem embedded adalah sistem komputasi yang menjadi bagian dari produk atau sistem yang lebih besar, biasanya dirancang untuk fungsi tertentu. Ia dapat berupa microcontroller kecil tanpa sistem operasi, atau SoC modern yang menjalankan Linux embedded. Yang membuatnya “embedded” bukan ukuran semata, melainkan perannya: komputer itu ditanamkan untuk mengendalikan, mengukur, mengomunikasikan, atau mengotomasi sesuatu. Dalam literatur cyber-physical systems, perangkat komputasi sering dipahami sebagai bagian dari sistem yang berinteraksi dengan proses fisis melalui sensor dan aktuator (Lee dan Seshia, 2017).

Contohnya:

• sensor kelembapan membaca nilai dari sensor analog, lalu mengirim data melalui MQTT;
• ECU kendaraan membaca posisi pedal, menghitung respons, lalu mengendalikan aktuator;
• PLC industri membaca input dari mesin, menjalankan logika kontrol, lalu mengaktifkan relay;
• robot mobile membaca kamera dan encoder, merencanakan gerak, lalu menggerakkan motor.

Pada sistem IT biasa, kegagalan keamanan sering dibayangkan sebagai kebocoran data, pencurian akun, atau pengambilalihan server. Pada sistem embedded, dampaknya dapat lebih luas. Serangan dapat memengaruhi data, layanan, perangkat fisik, proses industri, keselamatan pengguna, atau kepercayaan terhadap seluruh produk. Standar otomotif modern, misalnya, memperlakukan cybersecurity sebagai proses rekayasa sepanjang siklus hidup kendaraan, bukan sekadar fitur tambahan di akhir pengembangan (ISO/SAE, 2021). Dalam sistem otomasi industri, keamanan produk juga dikaitkan dengan proses pengembangan aman dan pengelolaan kerentanan sepanjang umur produk (IEC, 2018).

Perbedaan pentingnya terletak pada beberapa hal.

Pertama, sistem embedded dekat dengan hardware. Firmware tidak hanya memanggil API tingkat tinggi, tetapi sering menulis langsung ke register peripheral, mengatur pin GPIO, membaca flash, mengonfigurasi clock, menangani interrupt, atau mengakses memory-mapped I/O. Bug kecil pada satu bit konfigurasi dapat mengubah perilaku seluruh sistem.

Kedua, sistem embedded sering memiliki keterbatasan sumber daya. RAM kecil, flash terbatas, CPU hemat daya, bandwidth rendah, dan konsumsi energi ketat. Mekanisme keamanan yang lazim di server—misalnya sandbox berat, logging lengkap, atau pembaruan besar—tidak selalu dapat diterapkan langsung.

Ketiga, banyak perangkat memiliki siklus hidup panjang. Perangkat industri, kendaraan, atau infrastruktur bisa beroperasi jauh lebih lama daripada smartphone. Sementara itu, algoritma kriptografi, library, dependency, dan pola serangan terus berubah. Karena itu, kemampuan update aman dan pengelolaan kunci menjadi bagian inti dari desain, bukan fitur opsional.

Keempat, attacker mungkin memiliki akses fisik. Pada aplikasi cloud murni, attacker jarang memegang server secara langsung. Pada embedded systems, attacker dapat membeli perangkat yang sama, membuka casing, mencari pin UART, menghubungkan debugger, membaca flash eksternal, mengukur konsumsi daya, atau mencoba fault injection. Karena alasan ini, keamanan firmware dan hardware interface harus dipelajari bersama.

Keamanan sebagai pertanyaan tentang kepercayaan

Salah satu mental model terpenting dalam buku ini adalah: keamanan adalah ilmu mengelola kepercayaan dalam sistem yang dapat diserang.

Setiap sistem mempercayai sesuatu. Pertanyaannya bukan “apakah sistem ini percaya?”, melainkan “apa yang dipercaya, siapa yang dipercaya, dalam kondisi apa, dan apa akibatnya jika kepercayaan itu keliru?”

Misalnya, sebuah bootloader mungkin mempercayai firmware yang tersimpan di flash internal. Jika bootloader langsung menjalankan firmware tanpa verifikasi tanda tangan digital, berarti sistem menganggap isi flash selalu benar dan tidak pernah dimodifikasi. Jika attacker dapat menulis ulang flash, asumsi itu runtuh.

Contoh lain: sebuah perangkat IoT mungkin menerima perintah konfigurasi dari server cloud. Jika perangkat tidak memverifikasi identitas server, maka perangkat sebenarnya mempercayai siapa pun yang dapat meniru server tersebut. Jika komunikasi tidak dilindungi dengan autentikasi dan integritas, attacker di jaringan dapat mengubah perintah.

Dalam security engineering, prinsip seperti least privilege, fail-safe defaults, dan complete mediation telah lama digunakan untuk menilai apakah sistem memberi akses terlalu luas, gagal dalam keadaan tidak aman, atau melewati pemeriksaan akses pada jalur tertentu (Saltzer dan Schroeder, 1975). Prinsip-prinsip ini tetap relevan pada sistem embedded, tetapi penerapannya harus memahami konteks hardware, firmware, real-time behavior, dan lifecycle perangkat.

Perhatikan contoh berikut:

[ Sensor ] -> [ Firmware ] -> [ Wi-Fi Module ] -> [ Cloud ]
     |              |                |               |
  data fisis     parsing        protokol        backend

Jika firmware menerima data dari sensor melalui I2C, apakah sensor itu dipercaya? Jika sensor dapat diganti attacker, apakah firmware tetap aman? Jika modul Wi-Fi menerima data dari jaringan, apakah firmware memvalidasi panjang pesan? Jika cloud mengirim update, apakah update diverifikasi secara kriptografis sebelum dipasang?

Pertanyaan-pertanyaan ini akan muncul berkali-kali sepanjang buku.

Istilah dasar yang akan sering muncul

Sebelum masuk ke bab teknis, kita perlu menyepakati beberapa istilah.

Asset adalah sesuatu yang bernilai dan perlu dilindungi. Pada embedded systems, asset tidak selalu berupa file rahasia. Asset dapat berupa kunci kriptografi, firmware, konfigurasi, identitas perangkat, data pengguna, log, akses ke aktuator, kalibrasi sensor, keselamatan proses, atau reputasi produk.

Contoh: pada smart lock, asset-nya mencakup kunci digital, mekanisme pembuka kunci, firmware, pairing credential, dan kemampuan membuka pintu.

Threat atau ancaman adalah kemungkinan tindakan atau kondisi yang dapat merugikan asset. Ancaman dapat berupa attacker yang mencoba mengambil firmware, mengirim paket palsu, menurunkan versi firmware ke versi rentan, atau memanipulasi sensor.

Contoh: pada sensor industri, ancaman dapat berupa attacker yang mengubah pembacaan suhu agar sistem kontrol mengambil keputusan salah.

Vulnerability atau kerentanan adalah kelemahan yang dapat dieksploitasi. Kelemahan itu dapat berada di kode, konfigurasi, desain protokol, proses update, desain hardware, atau prosedur operasional.

Contoh: fungsi C yang menyalin data UART ke buffer 64 byte tanpa memeriksa panjang input adalah vulnerability jika input dapat melebihi 64 byte.

Exploit adalah cara konkret menggunakan vulnerability untuk mencapai dampak tertentu. Exploit tidak selalu berupa program kompleks. Pada embedded systems, exploit bisa berupa urutan paket, file firmware yang dimodifikasi, sinyal pada pin boot mode, atau glitch tegangan pada waktu tertentu.

Attack surface adalah seluruh titik tempat attacker dapat berinteraksi dengan sistem. Pada laptop, attack surface mungkin mencakup browser, layanan jaringan, port USB, dan akun pengguna. Pada embedded systems, attack surface dapat mencakup UART, JTAG/SWD, SPI flash, I2C sensor, CAN bus, BLE, Wi-Fi, tombol fisik, update package, mobile app, cloud API, dan bahkan konsumsi daya.

Contoh sederhana:

                 Internet
                    |
                [ Cloud ]
                    |
                 TLS/MQTT
                    |
[ Mobile App ] -- [ Device ] -- UART test pad
                    |
                SPI flash
                    |
              Sensor / Aktuator

Setiap garis pada diagram itu dapat menjadi jalur data. Setiap jalur data membawa asumsi. Setiap asumsi dapat menjadi bagian dari model keamanan.

Threat modeling adalah proses sistematis untuk memetakan asset, attacker, trust boundary, aliran data, dan risiko. NIST mendefinisikan risk assessment sebagai proses mengidentifikasi, memperkirakan, dan memprioritaskan risiko terhadap operasi organisasi, aset, individu, organisasi lain, dan negara (NIST, 2012). Dalam buku ini, threat modeling akan kita gunakan sebagai cara berpikir praktis: sebelum memperbaiki sistem, kita harus tahu apa yang sedang dilindungi dan dari siapa.

Dari bit hingga risiko produk

Keamanan embedded tidak dapat dipahami hanya dari satu lapisan. Bug paling kecil dapat muncul sebagai instruksi mesin, tetapi dampaknya dapat menjadi risiko bisnis, risiko keselamatan, atau risiko privasi.

Misalnya, bayangkan firmware menerima perintah melalui UART:

char name[16];

void set_name(const char *input) {
    strcpy(name, input);
}

Bagi programmer C, masalahnya terlihat seperti penggunaan strcpy tanpa batas panjang. Pada tingkat memori, masalahnya adalah data dapat ditulis melewati batas array name. Pada tingkat eksekusi, data itu mungkin menimpa variabel lain, return address, atau metadata. Pada tingkat firmware, attacker mungkin dapat mengubah konfigurasi perangkat. Pada tingkat produk, perangkat dapat diambil alih. Pada tingkat organisasi, update darurat harus dikirim ke ribuan perangkat.

Jadi satu bug dapat dilihat dari banyak lapisan:

Kode C/C++ 
   -> tata letak memori 
      -> instruksi CPU 
         -> perilaku firmware 
            -> fungsi perangkat 
               -> risiko produk

Buku ini disusun untuk bergerak melalui lapisan-lapisan tersebut secara bertahap.

Kita mulai dari arsitektur komputer karena vulnerability firmware sering baru jelas ketika kita memahami register, stack pointer, program counter, exception, dan memory map. Kita lanjut ke microcontroller dan board-level design karena keputusan hardware menentukan apakah debug port dapat dikunci, apakah flash dapat dibaca, dan bagaimana perangkat bisa dipulihkan setelah update gagal. Kita kemudian masuk ke C/C++, memory safety, interrupt, peripheral, boot process, kriptografi, key management, secure update, reverse engineering, fuzzing, runtime hardening, network security, threat modeling, physical security, side-channel, fault injection, secure storage, dan studi kasus.

Urutannya bukan kebetulan. Setiap konsep menjadi fondasi untuk konsep berikutnya.

Firmware: software yang dekat dengan kepercayaan awal

Firmware adalah software yang disimpan dalam media non-volatile—misalnya flash—dan mengendalikan hardware secara langsung atau semi-langsung. Firmware bisa sangat kecil, seperti loop utama pada microcontroller, atau sangat besar, seperti image Linux embedded dengan bootloader, kernel, device tree, filesystem, dan aplikasi.

Firmware sering menjadi bagian dari jalur kepercayaan awal perangkat. Ketika perangkat dinyalakan, CPU mulai mengeksekusi instruksi dari alamat tertentu atau dari ROM bootloader internal. Dari sana, perangkat memuat bootloader, memverifikasi atau menjalankan firmware, menginisialisasi memori, mengatur peripheral, lalu masuk ke aplikasi utama. NIST SP 800-193 menekankan pentingnya mekanisme resiliency firmware, termasuk proteksi, deteksi, dan pemulihan firmware platform dari modifikasi tidak sah atau korupsi (NIST, 2018).

Ini penting karena jika attacker dapat mengganti firmware, attacker tidak hanya memperoleh akses ke aplikasi. Ia dapat mengubah aturan dasar perangkat: menonaktifkan logging, mencuri kunci, melewati autentikasi, memalsukan sensor, atau membuat perangkat tampak normal saat sebenarnya sudah dikompromikan.

Karena itu, topik seperti secure boot, firmware signing, anti-rollback, secure storage, dan debug lock bukan fitur kosmetik. Mereka adalah cara untuk menjawab pertanyaan mendasar: “Bagaimana perangkat tahu bahwa kode yang dijalankannya adalah kode yang benar?”

Kriptografi bukan sekadar algoritma

Banyak pemula mengira keamanan embedded berarti “tambahkan AES” atau “pakai TLS”. Ini awal yang wajar, tetapi belum cukup.

Kriptografi adalah alat untuk menyediakan fungsi keamanan seperti kerahasiaan, integritas, autentikasi, dan non-repudiation dalam kondisi tertentu. Namun alat itu hanya benar-benar berguna jika dipakai dalam desain yang benar. Kunci harus dibuat dengan sumber randomness yang baik, disimpan dengan aman, diputar bila perlu, dicabut bila kompromi, dan tidak dibocorkan melalui log, debug port, firmware image, atau side-channel.

Contoh: tanda tangan digital pada firmware update dapat memastikan firmware berasal dari pembuat yang sah dan tidak diubah. Namun jika private key signing tersimpan di server build tanpa proteksi, attacker yang mencurinya dapat menandatangani firmware jahat. Dalam kasus itu, algoritma tanda tangan mungkin kuat, tetapi sistem key management gagal.

NISTIR 8259A memasukkan identitas perangkat, konfigurasi aman, proteksi data, akses interface logis, update software dan firmware, serta kemampuan cybersecurity state awareness sebagai kapabilitas inti yang perlu dipertimbangkan pada perangkat IoT (Fagan et al., 2020). Artinya, keamanan perangkat tidak berdiri pada satu mekanisme, tetapi pada kombinasi kemampuan yang dirancang sejak awal.

Attacker pada embedded systems

Dalam buku ini, attacker bukan tokoh abstrak yang selalu mahakuat. Kita akan membedakan kemampuan attacker.

Ada attacker jaringan yang hanya dapat mengirim paket. Ada attacker lokal yang dapat mengakses Bluetooth atau Wi-Fi jarak dekat. Ada attacker dengan akses fisik yang dapat membuka casing. Ada attacker laboratorium yang memiliki logic analyzer, debugger, hot air station, oscilloscope, atau alat glitching. Ada juga insider yang memiliki akses ke source code, proses produksi, atau private key.

Perbedaan kemampuan ini penting. Mitigasi yang cukup untuk attacker jaringan belum tentu cukup untuk attacker dengan akses fisik. Sebaliknya, tidak semua produk harus dirancang untuk menahan serangan laboratorium mahal selama berminggu-minggu. Security engineering selalu melibatkan konteks, biaya, dampak, dan prioritas. Ross Anderson menekankan bahwa rekayasa keamanan bukan hanya tentang kriptografi atau protokol, tetapi tentang membangun sistem yang tetap dependable ketika berhadapan dengan kegagalan, insentif, manusia, dan adversary (Anderson, 2020).

Kita akan menghindari dua ekstrem. Ekstrem pertama adalah meremehkan: “perangkat ini kecil, tidak ada yang akan menyerang.” Banyak serangan justru terjadi karena perangkat kecil dipasang massal dan jarang dipantau. Ekstrem kedua adalah perfeksionisme: “kalau tidak bisa melawan semua serangan fisik tingkat tinggi, semua percuma.” Dalam rekayasa nyata, tujuan kita adalah mengurangi risiko secara proporsional, membuat serangan lebih sulit, membatasi dampak, mendeteksi anomali, dan menyediakan pemulihan.

Etika, legalitas, dan batas eksperimen

Keamanan siber dapat dipelajari secara aman dan etis. Prinsipnya sederhana: lakukan eksperimen hanya pada sistem yang Anda miliki, diizinkan untuk diuji, atau disediakan khusus sebagai lab. Jangan mengakses perangkat, jaringan, firmware, layanan cloud, kendaraan, robot, PLC, atau sistem industri milik orang lain tanpa izin eksplisit.

Buku ini akan membahas reverse engineering, fuzzing, firmware extraction, debug interface, side-channel, dan fault injection dari sudut pandang pembelajaran dan engineering defensif. Tujuannya adalah memahami risiko agar dapat merancang mitigasi, melakukan audit yang sah, dan memperbaiki sistem. Ketika nanti kita melakukan mini-project, eksperimen akan diarahkan pada program lab, board milik sendiri, firmware latihan, atau lingkungan lokal terisolasi.

Sikap profesional sangat penting. Engineer keamanan yang baik tidak hanya bertanya, “Bisakah ini ditembus?”, tetapi juga, “Apa izin saya? Apa dampaknya? Bagaimana saya mendokumentasikan temuan? Bagaimana perbaikan dapat dilakukan tanpa membahayakan pengguna?”

Peta belajar buku ini

Buku ini bergerak dari fondasi menuju praktik.

Pada bagian awal, kita membangun model mental tentang komputer embedded: CPU, register, memori, stack, heap, interrupt, bus, peripheral, bootloader, dan hubungan antara hardware dan firmware. Bagian ini penting karena banyak vulnerability firmware bukan misteri; ia adalah konsekuensi dari eksekusi mesin yang sangat konkret.

Pada bagian menengah, kita membahas C/C++, memory safety, concurrency, peripheral sebagai attack surface, boot process, kriptografi, key management, secure boot, dan secure update. Di sini kita mulai melihat pola: input yang tidak divalidasi, asumsi trust boundary yang salah, kunci yang disimpan sembarangan, update yang tidak atomik, dan debug interface yang tertinggal aktif.

Pada bagian berikutnya, kita masuk ke debugging, firmware analysis, reverse engineering, vulnerability analysis, fuzzing, secure coding, runtime hardening, dan network security. Tujuannya agar pembaca dapat membaca sistem yang sudah ada, bukan hanya merancang sistem baru dari nol.

Pada bagian akhir, kita menyatukan semuanya melalui threat modeling, physical security, side-channel, fault injection, secure storage, studi kasus IoT, automotive, robotics, industrial systems, mini-project, dan proses engineering produk aman.

Jika diringkas, alur buku ini adalah:

Cara komputer bekerja
   -> cara firmware dibangun
      -> cara bug muncul
         -> cara attacker memanfaatkannya
            -> cara engineer memitigasinya
               -> cara organisasi memelihara keamanan produk

Cara berpikir yang ingin dibangun

Setelah membaca buku ini, Anda diharapkan tidak hanya mengenal istilah, tetapi mampu bertanya dengan tajam.

Saat melihat UART terbuka, Anda bertanya: apakah ini debug console? Apakah ada autentikasi? Apakah tersedia di produk produksi? Apakah dapat mengubah konfigurasi?

Saat melihat firmware update, Anda bertanya: siapa yang menandatangani firmware? Apa yang diverifikasi bootloader? Apakah downgrade dicegah? Apa yang terjadi jika listrik mati di tengah update?

Saat melihat parser protokol, Anda bertanya: dari mana input berasal? Apakah panjang input diperiksa? Apakah integer overflow mungkin terjadi? Apakah state machine memiliki transisi yang tidak valid?

Saat melihat kunci kriptografi, Anda bertanya: kapan dibuat? Di mana disimpan? Siapa yang dapat membacanya? Bagaimana rotasi dan revocation dilakukan? Apakah kunci yang sama dipakai di semua perangkat?

Saat melihat sistem robotik atau industri, Anda bertanya: apakah isu ini hanya confidentiality, atau juga safety dan availability? Apakah mekanisme keamanan mengganggu determinism atau real-time constraint? Bagaimana mode gagal yang aman?

Pertanyaan-pertanyaan ini adalah inti dari keamanan embedded. Teknik akan berubah, microcontroller akan berganti, protokol baru akan muncul, tetapi cara berpikir tentang asset, trust boundary, attack surface, vulnerability, exploit, impact, dan mitigasi akan tetap berguna.

Mari mulai dari peta besar.

References

Anderson, R. (2020). Security Engineering: A Guide to Building Dependable Distributed Systems (3rd ed.). Wiley.

Fagan, M., Megas, K. N., Scarfone, K., & Smith, M. (2020). IoT Device Cybersecurity Capability Core Baseline (NISTIR 8259A). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.IR.8259A

IEC. (2018). IEC 62443-4-1:2018 Security for industrial automation and control systems — Part 4-1: Secure product development lifecycle requirements. International Electrotechnical Commission.

ISO/SAE. (2021). ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering. International Organization for Standardization.

Lee, E. A., & Seshia, S. A. (2017). Introduction to Embedded Systems: A Cyber-Physical Systems Approach (2nd ed.). MIT Press.

NIST. (2012). Guide for Conducting Risk Assessments (NIST Special Publication 800-30 Revision 1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-30r1

NIST. (2018). Platform Firmware Resiliency Guidelines (NIST Special Publication 800-193). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-193

Saltzer, J. H., & Schroeder, M. D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278–1308. https://doi.org/10.1109/PROC.1975.9939