14.3.4. Catatan tentang perlindungan readout flash

Secara default, firmware pada OpenMV cam yang dikirimkan dapat dibaca oleh siapa saja yang memiliki akses fisik ke perangkat. Seorang penyerang yang memegang kamera dapat menghubungkan probe SWD ke header debug, berkomunikasi dengan antarmuka debug MCU, dan men-dump flash -- yang mencakup setiap modul Python yang dibekukan dan isi partisi ROMFS. Firmware OpenMV standar tidak mengaktifkan perlindungan readout flash secara default.

Halaman ini mendokumentasikan hal tersebut secara eksplisit sehingga tim yang mengirimkan produk mengetahui di mana tanggung jawab berada.

14.3.4.1. Apa yang dilakukan kamera secara default

Bootloader dan runtime kamera tidak mengaktifkan fitur perlindungan readout pada MCU yang mendasarinya. Antarmuka debug tetap terbuka, flash tetap dapat dibaca, dan build berjalan seperti yang dilakukan di meja pengembang. Itulah default yang tepat untuk audiens tutorial -- kamera yang dikirimkan dengan perlindungan readout aktif adalah kamera yang tidak dapat di-flash ulang melalui IDE, tidak dapat di-image ulang setelah deployment yang gagal, dan tidak dapat diselamatkan oleh siapa pun kecuali tim build.

Kompromi berubah ketika kamera beralih dari "perangkat pengembang" menjadi "produk." Sebuah produk yang nilainya bergantung pada kerahasiaan kode aplikasi harus mengaktifkan perlindungan sendiri; firmware OpenMV tidak melakukannya.

14.3.4.2. Apa yang dilakukan tim produk

Setiap vendor MCU menawarkan mekanisme perlindungan readout. Detailnya berbeda-beda -- fuse tingkat bit, transisi lifecycle satu kali, image flash yang ditandatangani -- tetapi bentuk umumnya adalah:

  • Bit (atau kumpulan bit) khusus vendor di-commit ke silikon, biasanya melalui alat vendor yang berkomunikasi dengan port debug MCU untuk terakhir kalinya.

  • Setelah commit, port debug menolak untuk membaca flash. Kamera tetap boot dan menjalankan aplikasi; hanya saja tidak lagi mengekspos isinya ke probe.

  • Commit tersebut tidak dapat dibalikkan. Tidak ada cara untuk mengembalikan kamera ke kondisi yang dapat di-debug tanpa menghancurkannya.

Mengatur ini bersifat spesifik MCU, dan langkah-langkahnya bergantung pada komponen di kamera yang dilindungi. Manual referensi vendor adalah sumber kebenaran; dukungan vendor adalah saluran untuk melakukannya dengan benar pada lini produksi.

Ini adalah bagian yang mudah.

Bagian yang sulit adalah menutup setiap jalur lain yang dimiliki penyerang untuk menjalankan kode pada kamera atau membaca apa yang dilakukan aplikasi. Perlindungan readout hanya menghentikan probe debug dari men-dump flash. Kamera masih harus menutup:

  • MicroPython REPL. REPL yang terhubung melalui USB menerima Python arbitrer. Perlindungan readout tidak mengubah itu. Sesi REPL dapat membaca RAM, memanggil fungsi, mengeksfiltrasi apa pun yang dapat dilihat oleh aplikasi yang berjalan -- secara efektif, REPL yang dapat dijangkau mengabaikan semua yang dibeli oleh perlindungan readout. Menonaktifkan akses REPL adalah perubahan build firmware yang dimiliki oleh tim produk.

  • Pengunggahan skrip IDE. Jalur "jalankan skrip ini di kamera" milik IDE menggunakan permukaan protokol USB yang sama dengan REPL. Menutup REPL menutup ini bersamanya; membiarkan salah satunya terbuka meninggalkan saluran eksekusi kode arbitrer ke dalam kamera.

  • Pembajakan titik masuk dari filesystem. Sudah ditutup ketika aplikasi dikirimkan melalui Membekukan skrip ke dalam firmware -- runtime menyelesaikan boot.py dan main.py yang dibekukan sebelum salinan filesystem apa pun, sehingga tidak ada yang ditaruh di flash atau SD yang dapat menggantinya. Perlindungan ini gratis begitu aplikasi ada dalam build.

  • Flash eksternal pada kamera yang lebih baru. Kamera yang menyimpan image aplikasi dalam flash eksternal menempatkan image tersebut pada chip yang terlihat jelas di PCB; chip tersebut dapat dilepas dan dibaca langsung dengan alat siap pakai, atau dibaca di tempat dengan melakukan probe pada bus. Melindunginya memerlukan pengaktifan hardware on-chip yang mendekripsi isi flash selama pembacaan, menghasilkan kunci enkripsi, menyediakan kunci tersebut ke kamera, dan membakarnya secara permanen ke penyimpanan one-time-programmable MCU. Setiap operasi tersebut adalah operasi satu kali yang terpisah, dan salah satu yang dilakukan salah pada unit produksi akan merusak unit tersebut.

Setiap item dalam daftar ini adalah tumpukan pekerjaan build firmware, langkah-langkah lini produksi, dan commit yang tidak dapat dibalikkan tersendiri. Produk yang benar-benar terkunci adalah build firmware yang dikustomisasi, bootloader yang dikustomisasi, alur produksi yang menyediakan kunci per unit, dan serangkaian pengujian yang membuktikan kunci benar-benar tertutup sebelum unit meninggalkan lini. Itu adalah pekerjaan berbulan-bulan, bukan berhari-hari, dan ketidakbalikannya berarti kesalahan menghabiskan unit.

Mengapa defaultnya terbuka

Daftar ini juga menjelaskan mengapa firmware OpenMV standar dikirimkan tanpa perlindungan readout yang diaktifkan. Kamera dengan REPL ditutup, pengunggahan skrip IDE dinonaktifkan, dan firmware dikunci adalah kamera yang sama sekali tidak dapat dikembangkan -- alur kerja yang membuat OpenMV cam dapat digunakan sejak awal akan hilang begitu saja. Default membiarkan semuanya terbuka; tim produk memilih bagian mana yang akan ditutup dalam perjalanan menuju unit yang dikirimkan.

14.3.4.3. Apa yang masih dapat dilakukan akses fisik

Bahkan dengan perlindungan readout aktif, penyerang yang memegang kamera dapat melakukan cukup banyak hal:

  • Memutar ulang lalu lintas jaringan kamera dengan mengendus outputnya.

  • Mengamati perilaku yang terlihat dan menyimpulkan bagaimana kamera bereaksi terhadap input.

  • Dalam beberapa kasus, memulihkan rahasia melalui serangan fault-injection atau side-channel yang dikhususkan terhadap MCU yang dilindungi.

Perlindungan readout meningkatkan biaya untuk mendapatkan kode sumber aplikasi. Ini tidak menghilangkan biaya tersebut. "Akses fisik = kompromi" adalah asumsi kerja yang harus dimulai oleh tinjauan keamanan; mekanisme perlindungan hanya menentukan berapa banyak biaya kompromi tersebut dalam hal waktu dan peralatan.

14.3.4.4. Apa yang disertakan firmware OpenMV

Ringkasan, agar ini konkret:

  • Tidak ada perlindungan readout yang diaktifkan secara default.

  • Tidak ada flag build dalam firmware standar yang mengaktifkannya.

  • Tidak ada API tingkat aplikasi untuk dipanggil dari MicroPython.

Produk yang membutuhkan perlindungan mengirimkan firmware yang dikustomisasi. Kustomisasi tersebut berada dalam bootloader papan dan alur produksi, dan berada di luar basis kode OpenMV. Tim yang melakukan ini untuk pertama kalinya harus merencanakannya ke dalam jadwal pengembangan sebagai bagian pekerjaan yang terpisah, bukan sebagai sesuatu yang ditambahkan di akhir -- ketidakbalikannya membuat "tambahkan nanti" menjadi mahal.