SDV AAOS - Aman dari Desain

Di Google, kami yakin bahwa produk kami harus aman sejak desainnya. Itulah sebabnya kami membangun Sistem Operasi Android Automotive untuk Kendaraan yang Ditentukan Software (AAOS SDV) di platform yang sudah ada dan terbukti di pasar, dengan memanfaatkan teknologi virtualisasi seperti Cuttlefish. Meskipun pengumuman rilis kami berfokus pada fitur, postingan blog ini menguraikan beberapa konsep keamanan.

Dasar: Isolasi Domain

Virtualisasi untuk mengisolasi instance yang di-hosting 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, sering kali lebih baik menjalankan domain logis secara independen. Misalnya, cluster dan sistem infotainment memiliki persyaratan yang berbeda. Kami menggunakan mesin virtual 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 mesin virtual privasi (pVM). Silsilah ini memberi para engineer platform Android fitur keamanan yang sudah mapan dan mereka ketahui.

Isolasi Proses & Penolakan 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 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 ke sistem izin komunikasi kami, seperti yang dijelaskan nanti dalam artikel ini.

Pengelolaan Kerentanan yang Terbukti

SDV AAOS mengintegrasikan infrastruktur respons keamanan dan manajemen kerentanan Android yang matang untuk mengidentifikasi, melakukan triase, memperbaiki, dan mengungkapkan temuan keamanan. Siklus proses ini mencakup pemindaian otomatis berkelanjutan, pengujian penetrasi mendalam tahunan, dan intelijen yang didorong partner melalui proses pelaporan kerentanan keamanan Android. Tim keamanan memilah 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 yang Diautentikasi

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 mengapsulasi 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 diatasi melalui empat pilar inti: 

1. Penyimpanan yang Tidak Dapat Diubah

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

2. Integritas Kriptografi

• Mekanisme: Tanda tangan kriptografi memvalidasi Hierarki Merkle dari seluruh image sistem file.
• Alasan mengapa ini lebih aman: 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: Ini menerapkan aturan isolasi proses seperti yang dijelaskan di bagian Isolasi Proses untuk membuat sandbox, dengan APEX yang di-mount sebagai partisi khusus di /apex.
• Mengapa lebih aman: 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 linker khusus, sehingga hanya library yang diekspos secara eksplisit yang dapat diakses dari daemon sistem yang tidak memiliki hak istimewa, sehingga meminimalkan permukaan serangan.

4. Pemulihan Atomik

• Mekanisme: APEX menggunakan desain "Aktif/Cadangan" untuk mengaktifkan rollback buffer ganda. APEX yang di-flash pabrik tetap berada di partisi /system yang tidak dapat diubah, sementara update berada di partisi /data yang dapat diubah.
• Alasan mengapa fitur ini lebih aman: 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 keadaan rusak.

Ketahanan: Pengembangan yang Aman 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 pembangunan di stack Android penuh, jadi kami membatasi cakupan kami ke 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. Menurut desainnya, 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 secara kriptografi versi dan penulis setiap endpoint komunikasi.

Penyediaan Perangkat dan Mesh

Mesh SDV AAOS menetapkan autentikasi dengan mengikat identitas jaringan setiap komponen secara matematis ke status eksekusi biner sebenarnya. Model ini menggantikan kepercayaan software implisit dengan verifikasi yang di-rooting hardware.

Autentikasi mesh dirancang agar berkelanjutan dan kriptografis. Hal ini mencegah skenario di mana, misalnya, layanan seperti gateway kendaraan mempercayai VM infotainment yang disusupi hanya karena VM tersebut 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 mencegah eksekusi kode atau pengubahan konfigurasi yang tidak sah.

TLS berbasis DICE untuk mengamankan komunikasi VM-ke-VM

Mendasarkan identitas host pada kenyataan

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

DICE dan TLS (Transport Layer Security) terintegrasi untuk memecahkan 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 softwarenya yang tepat.

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

• Secret Perangkat Unik (UDS): Secret kriptografi acak yang dibuat selama pembuatan. Hanya bootloader tahap pertama yang dapat mengakses UDS; UDS tetap tidak dapat diakses oleh semua software dan antarmuka eksternal lainnya.
• Pengukuran Bertingkat (ID Perangkat Gabungan): ROM hardware memulai rantai dengan melakukan hashing UDS dengan kode yang tepat dan konfigurasi lapisan firmware berikutnya. Tindakan ini akan membuat CDI, yang kemudian dirantai secara berurutan saat setiap lapisan berikutnya melakukan booting.

Kontrol akses 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 pertahanan mendalam untuk mengaktifkan update kendaraan 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: Tentukan batas komunikasi antar-VM untuk semua layanan yang dihosting di VM tertentu.

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

Sebaliknya, izin untuk sinyal yang sensitif terhadap keamanan harus dikodekan secara permanen ke dalam setiap VM. Sebagai gantinya, pengenalan layanan yang sensitif terhadap keamanan ke VM baru memerlukan pembaruan sistem izin tingkat VM di seluruh sistem. Hal ini memerlukan update pada semua VM dalam mesh.

Kesimpulan

SDV AAOS memperluas arsitektur keamanan Android untuk memenuhi persyaratan otomotif tertentu melalui pendekatan secure-by-design. Dengan memanfaatkan virtualisasi untuk isolasi domain dan menerapkan kebijakan akses "tolak secara default", platform ini menciptakan lingkungan yang tangguh untuk kendaraan software-defined. Integritas kriptografi dipertahankan melalui verifikasi kode yang dieksekusi secara langsung dan diberlakukan oleh hardware.

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