AAOS SDV - Aman dari Desain

Di Google, kami percaya bahwa produk kami harus aman dari desain. Itulah sebabnya kami membangun Sistem Operasi Android Automotive untuk Software Defined Vehicle (AAOS SDV) di platform yang 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.

Fondasi: Isolasi Domain

Virtualisasi untuk mengisolasi instance yang dihosting bersama

Tren saat ini yang mengonsolidasikan Electronic Control Unit (ECU) ke dalam satu chip mengurangi isolasi dengan menjalankan beberapa domain secara berdampingan.

Meskipun instance AAOS SDV 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

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

Isolasi Proses &Tolak secara Default

AAOS SDV 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 memasangkannya dengan Security-Enhanced Linux (SELinux) untuk menerapkan postur "tolak secara default". Pendekatan ini membatasi setiap layanan ke minimum absolut yang diperlukan, yang berarti konfigurasi yang tidak ada akan memblokir akses, bukan membuat sistem yang terlalu permisif. Kami menerapkan strategi yang sama ke sistem izin komunikasi kami, seperti yang dijelaskan nanti dalam artikel ini.

Manajemen Kerentanan yang Terbukti

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

AAOS SDV 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 merangkum software dan dependensinya, memperlakukan paket sebagai partisi dengan validasi tanda tangan wajib. Di AAOS SDV, 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 mengulang file apex_payload.img secara langsung sebagai perangkat penyimpanan mentah menggunakan loopback hanya baca, memasangnya dengan flag MS_RDONLY yang ketat.
• Mengapa lebih aman: Hal ini tidak mengekspos jalur tulis ke OS karena file tidak diekstrak ke penyimpanan kendaraan. Meskipun penyerang mendapatkan hak akses root, mereka tidak dapat mengubah kode APEX yang berjalan karena lapisan sistem file menolak semua perintah tulis.

2. Integritas Kriptografi

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

3. Isolasi Ketat

• Mekanisme: Hal ini menerapkan aturan isolasi proses seperti yang dijelaskan di bagian Isolasi Proses untuk membuat sandbox, dengan APEX dipasang sebagai partisi khusus di bawah /apex.
• Mengapa lebih aman: Setiap layanan menerima direktori pengguna dan direktori data sendiri, yang membatasi akses kecuali jika berbagi bersifat eksplisit. Dengan membuat partisi khusus, Android menetapkan namespace linker khusus, sehingga memastikan hanya library yang diekspos secara eksplisit yang dapat diakses dari daemon sistem non-privilege, 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, sedangkan update berada di partisi /data yang dapat diubah.
• Mengapa lebih aman: Jika update gagal atau tampak berbahaya, daemon apexd akan menandainya sebagai "gagal" selama booting awal. Sistem akan langsung menukar link simbolik kembali ke partisi /system. Pemulihan atomik ini membantu memastikan sistem tidak tetap dalam keadaan rusak.

Ketahanan: Pengembangan yang Aman untuk Memori

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

Rust sebagai bahasa utama

AAOS SDV menargetkan sistem kecil dengan persyaratan ketersediaan yang cepat; hal ini mencegah pembangunan di stack Android lengkap, sehingga 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, yang membantu partner menulis software yang aman. Menurut desainnya, Rust memanfaatkan fitur keamanan memori untuk membantu mencegah class 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 AAOS SDV mengatasi kompleksitas ini dengan memverifikasi versi dan penulis setiap endpoint komunikasi secara kriptografi.

Penyediaan Perangkat dan Mesh

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

Autentikasi mesh dirancang agar berkelanjutan dan kriptografi. Hal ini mencegah skenario ketika, misalnya, layanan seperti gateway kendaraan memercayai VM infotainment yang terganggu 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 memuat eksekusi kode yang tidak sah atau manipulasi konfigurasi.

TLS berbasis DICE untuk mengamankan komunikasi VM ke VM

Mendasarkan identitas host pada 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) yang diturunkan 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 software-nya yang tepat.

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

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

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

Kontrol Akses Berlapis

AAOS SDV menggunakan strategi pertahanan mendalam untuk mengaktifkan update kendaraan dinamis tanpa mengorbankan mekanisme akses. Model ini bergantung pada dua lapisan kepercayaan utama:

1. Izin tingkat layanan: Menentukan resource tertentu yang dapat diakses atau diekspos 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 kemampuan update. Untuk layanan yang tidak sensitif terhadap keamanan, kebijakan tingkat VM yang permisif memungkinkan penginstalan melalui update APEX ringan, bukan deployment ulang VM lengkap.

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

Kesimpulan

AAOS SDV memperluas arsitektur keamanan Android untuk mengatasi persyaratan khusus otomotif melalui pendekatan aman dari desain. Dengan memanfaatkan virtualisasi untuk isolasi domain dan menerapkan kebijakan akses "tolak secara default", platform ini menetapkan lingkungan yang tangguh untuk kendaraan software-defined. Integritas kriptografi dipertahankan melalui verifikasi kode yang dijalankan secara langsung dan diterapkan hardware.

Platform ini mengintegrasikan siklus proses keamanan berkelanjutan, mulai dari manajemen kerentanan proaktif hingga verifikasi identitas yang berakar pada 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 AAOS SDV.