AAOS SDV - Aman dari Desain

Di Google, kami percaya bahwa produk kami harus aman sejak desainnya, itulah sebabnya kami membangun Android Automotive Operating System untuk Software Defined Vehicle (AAOS SDV) di platform yang sudah terbukti di pasar, dengan memanfaatkan teknologi virtualisasi seperti Cuttlefish. Meskipun pengumuman rilis kami berfokus pada fitur, postingan blog ini menguraikan beberapa konsep keamanan.

Fondasi: Isolasi Domain

Virtualisasi untuk mengisolasi instance yang dihosting bersama

Tren saat ini dalam menggabungkan Unit Kontrol Elektronik (ECU) ke dalam satu chip mengurangi isolasi dengan menjalankan beberapa domain secara berdampingan.

Meskipun instance SDV AAOS menyediakan mekanisme isolasi internal, menjalankan domain logis secara independen sering kali lebih disukai. Misalnya, cluster dan sistem infotainmen memiliki persyaratan yang berbeda. Kami menggunakan virtual machine untuk menjalankan beberapa instance secara paralel, sehingga memastikan bahwa berbagi tetap eksplisit dan isolasi adalah perilaku default.

Keamanan Android yang Diwarisi

SDV AAOS dikembangkan dari Microdroid, versi Android minimalis yang dioptimalkan untuk virtual machine privasi (pVM). Silsilah ini memberi engineer platform Android fitur keamanan yang sudah ada dan mereka ketahui.

Isolasi Proses & Tolak secara Default

SDV AAOS mengikuti model isolasi berbasis ID Pengguna (UID) Android untuk menyiapkan sandbox bagi setiap aplikasi. Setiap layanan berjalan dalam proses khusus dengan UID unik untuk mengelola hak akses, direktori data, dan batasan lainnya. Kami menggunakan kemampuan Portable Operating System Interface (POSIX) untuk membatasi operasi secara ketat dan menggabungkannya dengan Security-Enhanced Linux (SELinux) untuk menerapkan postur "tolak secara default". Pendekatan ini membatasi setiap layanan ke tingkat minimum mutlak yang diperlukan, yang berarti konfigurasi yang tidak ada akan memblokir akses, bukan membuat sistem yang terlalu permisif. Kami menerapkan strategi yang sama ini pada sistem izin komunikasi kami, seperti yang dijelaskan nanti dalam artikel ini.

Manajemen Kerentanan yang Terbukti

SDV AAOS mengintegrasikan infrastruktur respons keamanan dan pengelolaan kerentanan Android yang matang untuk mengidentifikasi, melakukan triase, memulihkan, dan mengungkapkan temuan keamanan. Siklus proses ini mencakup pemindaian otomatis berkelanjutan, uji penetrasi mendalam tahunan, dan kecerdasan berbasis partner melalui proses pelaporan kerentanan keamanan Android. Tim keamanan melakukan triase terhadap kerentanan yang ditemukan, menetapkan rating tingkat keparahan berdasarkan risiko, dan melacak perbaikan hingga selesai. Kami mengoordinasikan kebijakan pengungkapan dan rilis melalui Buletin Keamanan Android bulanan, yang dilengkapi dengan audit keamanan berkala yang ketat dan peninjauan arsitektur yang komprehensif untuk memastikan ketahanan platform jangka panjang.

Integritas: Pengiriman Software yang Aman

Selain menjamin isolasi proses, platform yang aman harus memastikan integritas kode sebelum eksekusi. Kami mengamankan pengiriman software melalui pendekatan berikut:

Pengiriman Software Terautentikasi

SDV AAOS menyediakan dua metode penginstalan. Pertama, kami menginstal software langsung ke partisi sistem, produk, atau vendor hanya baca, yang memvalidasi tanda tangan pada setiap booting. Hal ini mengamankan komponen sistem dasar.

Kedua, kami menggunakan paket Android Pony EXpress (APEX) untuk layanan. Setiap APEX mengenkapsulasi software dan dependensinya, memperlakukan paket sebagai partisi dengan validasi tanda tangan wajib. Di SDV AAOS, APEX memperlakukan penandatanganan kode sebagai kontrak berkelanjutan yang diterapkan hardware. APEX memastikan eksekusi kode berbahaya dimitigasi melalui empat pilar inti: 

1. Penyimpanan yang Tidak Dapat Diubah

• Mekanisme: Kernel Android melakukan loop pada file apex_payload.img secara langsung sebagai perangkat penyimpanan mentah menggunakan loopback hanya baca, yang memasangnya dengan flag MS_RDONLY yang ketat.
• Alasan metode ini lebih aman: Metode ini tidak mengekspos jalur tulis ke OS karena file tidak diekstrak ke penyimpanan kendaraan. Meskipun penyerang mendapatkan hak istimewa root, mereka tidak dapat mengubah kode APEX yang sedang berjalan karena lapisan sistem file menolak semua perintah tulis.

2. Integritas Kriptografis

• Mekanisme: Tanda tangan kriptografis memvalidasi Merkle Tree dari seluruh image sistem file.
• Alasan keamanannya lebih tinggi: Kernel menggunakan dm-verity per blok untuk memverifikasi tanda tangan setiap blok data 4 KB secara langsung. Jika penyerang mengubah blok mentah pada memori flash, kernel akan mendeteksi ketidakcocokan hash dan segera menghentikan eksekusi.

3. Isolasi Ketat

• Mekanisme: Mekanisme ini menerapkan aturan isolasi proses seperti yang dijelaskan di bagian Isolasi Proses untuk membuat sandbox, dengan APEX yang dipasang sebagai partisi khusus di bagian /apex.
• Alasan keamanannya lebih tinggi: Setiap layanan menerima direktori pengguna dan direktori datanya sendiri, sehingga membatasi akses kecuali jika berbagi dilakukan secara eksplisit. Dengan membuat partisi khusus, Android membuat namespace penaut khusus, sehingga memastikan hanya library yang diekspos secara eksplisit yang dapat diakses dari daemon sistem tanpa hak istimewa, sehingga meminimalkan permukaan serangan.

4. Pemulihan Atomik

• Mekanisme: APEX menggunakan desain "Aktif/Cadangan" untuk mengaktifkan rollback buffering ganda. APEX yang di-flash dari pabrik tetap berada di partisi /system yang tidak dapat diubah, sedangkan update berada di partisi /data yang dapat diubah.
• Alasan keamanan yang lebih baik: Jika update gagal atau tampak berbahaya, daemon apexd akan menandainya sebagai "gagal" selama booting awal. Sistem akan langsung menukar link simbolis kembali ke partisi /system. Pemulihan atomik ini membantu memastikan sistem tidak tetap dalam status rusak.

Ketahanan: Pengembangan yang Aman untuk Memori

Pemuatan terverifikasi melindungi sistem dari modifikasi eksternal, tetapi ketahanan platform juga bergantung pada cara kode yang mendasarinya dibuat. Untuk komponen baru yang dikembangkan untuk SDV AAOS, kami memprioritaskan keamanan memori.

Rust sebagai bahasa utama

SDV AAOS menargetkan sistem kecil dengan persyaratan ketersediaan yang cepat; hal ini mencegah pembuatan di stack Android lengkap, sehingga kami membatasi cakupan kami pada framework native. Untuk membuat infrastruktur yang diperlukan untuk sistem terdistribusi, kami mengembangkan beberapa komponen selain infrastruktur yang ada dan mengadopsi Rust sebagai bahasa utama. Kami juga menggunakan Rust untuk mengembangkan logika bisnis layanan, sehingga membantu partner menulis software yang aman. Secara desain, Rust memanfaatkan fitur keamanan memori untuk membantu mencegah kelas umum kerentanan keamanan memori, sekaligus mendukung throughput tim saat menulis kode native.

Kepercayaan Terdistribusi: Kontrol Jaringan & Akses

Kendaraan software-defined memerlukan interaksi yang aman antara domain yang terisolasi. Arsitektur penyediaan mesh SDV AAOS mengatasi kompleksitas ini dengan memverifikasi versi dan pembuat setiap endpoint komunikasi secara kriptografis.

Penyediaan Perangkat dan Mesh

Mesh SDV AAOS membuat autentikasi dengan mengikat identitas jaringan setiap komponen secara matematis ke status eksekusi biner sebenarnya. Model ini menggantikan kepercayaan software implisit dengan verifikasi berbasis hardware.

Autentikasi mesh dirancang untuk bersifat berkelanjutan dan kriptografis. Hal ini mencegah skenario, misalnya, layanan seperti gateway kendaraan memercayai VM infotainment yang disusupi hanya karena memiliki alamat IP yang tepat.

Isolasi yang diterapkan hardware dan protokol karantina otomatis mengamankan platform. Perangkat peer dalam mesh SDV menggunakan autentikasi dan pengesahan berbasis DICE, seperti yang dijelaskan di bagian berikut, untuk membantu mengidentifikasi dan membatasi eksekusi kode yang tidak sah atau modifikasi konfigurasi.

TLS berbasis DICE untuk mengamankan komunikasi VM-ke-VM

Membumikan identitas host dalam realitas

Aturan Emas DICE (Device Identifier Composition Engine): Jika satu baris kode dalam firmware berubah (bahkan update kecil atau eksploitasi berbahaya), Compound Device Identifier (CDI) turunan akan berubah sepenuhnya, sehingga menghasilkan Kunci Alias yang sama sekali berbeda.

DICE dan TLS (Transport Layer Security) terintegrasi untuk mengatasi tantangan mendasar arsitektur zero-trust: mengautentikasi mesin sekaligus memverifikasi integritas software-nya.

Kombinasi identifikasi yang didukung hardware DICE dan handshake terenkripsi TLS memungkinkan mesin penerima memverifikasi identitas pemanggil dan status software-nya yang tepat.

Sertifikat tradisional hanya membuktikan kepemilikan rahasia; sertifikat tersebut tidak dapat mendeteksi modifikasi firmware. DICE mengatasi hal ini melalui pelapisan booting terukur:

• Unique Device Secret (UDS): Rahasia kriptografis acak yang dihasilkan selama pembuatan. Hanya bootloader tahap pertama yang dapat mengakses UDS; UDS tetap tidak dapat diakses oleh semua software dan antarmuka eksternal lainnya.
• Pengukuran Berlapis (ID Perangkat Gabungan): ROM hardware memulai rantai dengan melakukan hashing pada UDS dengan kode persis dan konfigurasi lapisan firmware berikutnya. Tindakan ini akan membuat CDI, yang kemudian dihubungkan secara berurutan saat setiap lapisan berikutnya melakukan booting.

Kontrol akses yang ketat mengatur interaksi layanan dalam mesh SDV AAOS. Sama seperti semua software SDV AAOS, kontrol akses ini diautentikasi, dan integritasnya dilindungi di tingkat perangkat dan di seluruh perangkat dalam mesh melalui autentikasi berbasis DICE.

Kontrol Akses Berlapis

SDV AAOS menggunakan strategi defense in depth untuk memungkinkan update kendaraan yang dinamis tanpa mengorbankan mekanisme akses. Model ini mengandalkan dua lapisan kepercayaan utama:

1. Izin tingkat layanan: Menentukan resource tertentu yang dapat diakses atau diekspos oleh layanan di VM tertentu di seluruh mesh.
2. Izin tingkat VM: Menentukan batas komunikasi lintas VM untuk semua layanan yang dihosting di VM tertentu.

Model ini memungkinkan OEM menyeimbangkan keamanan dengan kapasitas update. Untuk layanan yang tidak sensitif terhadap keamanan, kebijakan tingkat VM yang permisif memungkinkan penginstalan melalui update APEX ringan, bukan deployment ulang VM secara penuh.

Sebaliknya, izin untuk sinyal yang sensitif terhadap keamanan harus di-hard code ke setiap VM. Konsekuensinya adalah memperkenalkan layanan yang sensitif terhadap keamanan ke VM baru memerlukan pembaruan izin tingkat VM di seluruh sistem. Hal ini memerlukan update untuk semua VM dalam mesh.

Kesimpulan

SDV AAOS memperluas arsitektur keamanan Android untuk memenuhi persyaratan otomotif tertentu melalui pendekatan aman sesuai desain. Dengan memanfaatkan virtualisasi untuk isolasi domain dan menerapkan kebijakan akses "tolak secara default", platform ini membangun lingkungan yang tangguh untuk kendaraan software-defined. Integritas kriptografis dipertahankan melalui verifikasi langsung kode yang dieksekusi, yang diterapkan oleh hardware.

Platform ini mengintegrasikan siklus proses keamanan berkelanjutan, mulai dari manajemen kerentanan proaktif hingga verifikasi identitas berbasis hardware melalui DICE. Pertahanan berlapis ini memungkinkan OEM menyeimbangkan kapasitas update fitur lanjutan dengan keamanan yang kuat yang diperlukan untuk lingkungan otomotif modern. Spesifikasi teknis dan detail implementasi tersedia di halaman Ringkasan SDV AAOS.