GrapheneOS dapat mengubah cara Android mengisolasi aplikasi, cara layanan privileged diekspos, cara sistem operasi diverifikasi saat boot, dan seberapa besar kewenangan yang diberikan kepada Google Play. Namun, tidak setiap properti ponsel dapat diubah menjadi pengaturan sistem operasi.
IMEI adalah contoh yang jelas untuk melihat batas tersebut. Dokumentasi GrapheneOS menyatakan bahwa IMEI pada perangkat produksi tidak dapat diubah dan sistem operasi tidak dapat menambahkan dukungan untuk operasi itu karena hardware tidak mendukungnya. Perbedaannya bersifat arsitektural: Android mengendalikan sebagian besar software stack, tetapi modem seluler dan mekanisme identitas perangkat bukan sekadar data aplikasi yang tersimpan di user space Android.
Batas yang sama juga menjelaskan beberapa karakteristik GrapheneOS yang sekilas tampak tidak berkaitan: antarmukanya tetap familiar sebagai Android, Google Play dapat dijalankan sebagai aplikasi biasa yang disandbox ketika dipasang, integritas OS bergantung pada model Verified Boot Android, dan akses aplikasi ke hardware identifier dibatasi tanpa berpura-pura bahwa identifier tersebut tidak ada.
GrapheneOS berangkat dari Android, bukan mengganti arsitekturnya
GrapheneOS berbasis Android Open Source Project. Model keamanannya dibangun di atas primitive Android seperti UID per aplikasi, SELinux, Verified Boot, permission aplikasi, dan isolasi proses.
Karena itu, antarmuka yang terlihat tetap dikenali sebagai Android. GrapheneOS menambahkan pengaturan, aplikasi, lapisan kompatibilitas, dan kontrol keamanannya sendiri, tetapi bukan platform seluler terpisah dengan model aplikasi yang sama sekali berbeda. Android package, Android permission, profile Android, dan model keamanan kernel Android tetap menjadi fondasinya.
Hal ini relevan ketika GrapheneOS dibandingkan dengan proyek seperti LineageOS. Keduanya merupakan sistem operasi berbasis Android, tetapi masing-masing dapat mengambil keputusan yang sangat berbeda terkait dukungan perangkat, kompatibilitas, kustomisasi, dan security hardening sambil tetap menjalankan aplikasi melalui API dasar Android yang sama.
Dalam analisis security boundary, persoalan utamanya bukan apakah home screen terlihat berbeda. Yang perlu diperiksa adalah komponen mana yang mempunyai kewenangan atas suatu resource dan trust boundary mana yang harus dilewati untuk mengaksesnya.
Application sandbox adalah batas yang ditegakkan kernel
Android memberikan Linux user ID unik kepada setiap aplikasi dan menjalankan aplikasi dalam proses yang terisolasi. Kernel Linux menggunakan identitas tersebut untuk memisahkan resource aplikasi. SELinux menambahkan mandatory access control di atas model permission pengguna dan grup tradisional.
Aplikasi biasa tidak memperoleh akses bebas ke file, memory, atau layanan sistem milik aplikasi lain. Akses dimediasi melalui Android API, Binder interface, permission, dan mekanisme berbagi yang eksplisit.
GrapheneOS menambahkan hardening di sekitar model ini, bukan menggantikannya. Salah satu konsekuensi praktisnya adalah software tidak harus dihapus dari perangkat hanya karena berasal dari ekosistem yang memiliki banyak integrasi. Kewenangannya dapat dipersempit.
Contoh paling jelas adalah Google Play.
Sandboxed Google Play tetap aplikasi, bukan otoritas OS
GrapheneOS tidak menyertakan Google Play services di base operating system. Pengguna dapat memilih untuk memasang komponen resmi Google Play.
Di GrapheneOS, komponen tersebut berjalan di standard Android application sandbox tanpa integrasi privileged yang biasanya diberikan pada banyak sistem Android bawaan vendor. GrapheneOS menyediakan compatibility layer agar aplikasi tersebut tetap dapat berfungsi sebagai aplikasi biasa tanpa privilege sistem.
Batasnya dapat digambarkan seperti ini:
Google Play services
|
permission aplikasi biasa
|
Android app sandbox
|
layanan sistem GrapheneOSMemasang Google Play tidak otomatis memberinya akses tanpa batas ke sistem operasi atau data milik aplikasi lain. Permission dan batas profile tetap berlaku.
Model ini juga memperjelas salah satu kesalahpahaman tentang “de-Googling.” GrapheneOS tidak perlu menganggap software Google tidak berisiko. Pendekatannya adalah mengubah privilege model tempat software tersebut berjalan.
Hardware identifier tetap ada meskipun aplikasi tidak dapat membacanya
Membatasi akses ke sebuah identifier berbeda dengan mengubah identifier itu sendiri.
Android secara bertahap membatasi akses aplikasi ke hardware identifier yang tidak dapat di-reset. Sejak Android 10, aplikasi biasa tidak dapat memperoleh identifier seperti IMEI, serial number perangkat, serial number SIM, dan subscriber identifier melalui jalur permission umum yang lama. Akses dibatasi untuk kasus privileged yang ditentukan platform.
GrapheneOS mengikuti model tersebut dan menghapus sebagian akses legacy tambahan. Aplikasi biasa dapat dicegah membaca IMEI meskipun modem tetap memiliki IMEI dan jaringan seluler tetap dapat menggunakannya.
Perbedaannya dapat digambarkan sebagai:
IMEI ada pada identitas perangkat / modem
|
+--> cellular stack dan jalur sistem berizin
|
X--> aplikasi biasaProperti privasinya adalah access control, bukan mutasi identifier.
Karena itu, pernyataan “aplikasi tidak dapat membaca IMEI saya” tidak sama dengan “ponsel saya tidak memiliki IMEI yang stabil.”
Modem bukan sekadar aplikasi Android lain
Smartphone modern memiliki beberapa execution environment. Android berjalan pada application processor, sedangkan komunikasi seluler melibatkan subsystem modem/baseband dengan firmware vendor dan interface hardware.
Android berkomunikasi dengan subsystem tersebut melalui radio interface dan komponen vendor yang telah ditentukan. Sistem operasi dapat menyediakan kontrol, meminta operasi jaringan, mengelola state yang berkaitan dengan SIM, dan menerapkan policy pada akses. Itu tidak berarti Android memiliki seluruh persistent identity atau detail implementasi yang berada di dalam modem.
Dokumentasi GrapheneOS memberikan konsekuensi praktisnya secara eksplisit: perangkat produksi tidak mendukung perubahan IMEI melalui sistem operasi.
Ini merupakan prinsip sistem yang lebih luas. Software pada satu layer hanya dapat menegakkan properti terhadap resource yang dikendalikannya atau terhadap interface yang memang diekspos oleh layer di bawahnya.
aplikasi
|
Android framework
|
kernel + vendor interface
|
radio / modem firmware
|
identitas hardware selulerCustom Android OS hanya menempati sebagian dari stack tersebut.
Verified Boot melindungi OS tanpa memberi kendali atas semua komponen
Android Verified Boot membangun chain of trust dari hardware-protected root of trust menuju bootloader dan partisi yang diverifikasi. Pada perangkat yang terkunci, verifikasi boot dirancang untuk memastikan software yang dimuat adalah software yang diizinkan dan bukan partisi yang diam-diam telah diganti.
GrapheneOS menggunakan model keamanan platform ini, bukan menganggap unlocked bootloader sebagai kebutuhan permanen. Memasang alternate OS dan mengoperasikannya dengan aman adalah dua tahap berbeda: proses flashing membutuhkan jalur instalasi, sedangkan postur keamanan akhirnya bergantung pada pemulihan verified dan locked boot behavior yang didukung perangkat.
Verified Boot menjawab pertanyaan yang spesifik: apakah perangkat sedang mem-boot software yang diizinkan oleh root of trust yang dikonfigurasi?
Hal itu tidak berarti Android dapat menulis ulang state setiap peripheral. Verifikasi boot dan identitas modem berada pada control domain yang berbeda.
Model sederhananya:
hardware root of trust
|
bootloader
|
partisi Android terverifikasi
|
runtime GrapheneOS
batas terpisah:
modem seluler / radio firmwareArsitektur keamanan menjadi lebih jelas ketika properti-properti ini dipisahkan, bukan ketika “OS” dianggap sebagai satu layer yang memiliki kuasa atas seluruh perangkat.
Hardening GrapheneOS terutama mengurangi kewenangan dan attack surface
Banyak fitur GrapheneOS mengikuti pola yang sama.
Application sandboxing membatasi resource yang dapat dijangkau aplikasi yang terkompromi. Exploit mitigation tambahan membuat memory-corruption vulnerability lebih sulit diubah menjadi code execution yang andal. Kontrol network dan sensor mempersempit capability yang diekspos ke masing-masing aplikasi. User profile memberikan pemisahan data yang lebih kuat di antara kelompok aplikasi. Sandboxed Google Play menghapus integrasi privileged dari komponen yang masih dibutuhkan banyak aplikasi.
Kontrol tersebut tidak membutuhkan sistem operasi untuk memalsukan state hardware. Mekanismenya adalah mempersempit interface, privilege, dan attack surface yang dapat dijangkau.
Pendekatan ini berbeda dari rooting perangkat dan memberikan tool administrator akses tanpa batas. Root menambah kewenangan yang dapat dipakai software di dalam Android. Arah GrapheneOS umumnya sebaliknya: lebih sedikit jalur privileged, isolasi lebih kuat, dan lebih sedikit komponen yang dipercaya memegang akses sensitif.
GrapheneOS dan LineageOS memiliki sasaran utama yang berbeda
LineageOS juga merupakan sistem operasi berbasis Android dan mendukung paket Google Apps opsional pada banyak jalur instalasi perangkat. Ekosistemnya kuat pada perluasan dukungan perangkat dan penyediaan distribusi Android alternatif pada beragam hardware.
GrapheneOS menetapkan kebutuhan hardware yang lebih ketat karena desain keamanannya bergantung pada capability platform dan properti update tertentu. Karena itu, keputusan desainnya tidak dapat dipertukarkan begitu saja dengan ROM yang memprioritaskan ketersediaan hardware lebih luas atau kustomisasi.
Perbedaan praktisnya bukan bahwa satu proyek “menggunakan Android” dan yang lain tidak. Keduanya menggunakan Android. Perbedaannya terletak pada constraint yang diterima masing-masing proyek untuk memenuhi sasaran teknisnya.
Bagi GrapheneOS, mempertahankan Verified Boot yang kuat, mengurangi integrasi privileged, menjaga exploit mitigation, dan membatasi aplikasi merupakan pilihan arsitektural inti. Fitur yang mengharuskan batas-batas itu dilemahkan tidak sejalan dengan model tersebut.
IMEI menandai tepi model keamanan sistem operasi
IMEI merupakan test case yang berguna karena memaksa satu pertanyaan yang presisi: layer mana yang memiliki state ini?
GrapheneOS dapat mencegah aplikasi biasa memperoleh akses privileged ke identifier. Sistem ini dapat memperkuat runtime Android di sekitar radio stack. Sistem ini dapat mengendalikan layanan dan aplikasi Android mana yang diizinkan meminta operasi sensitif. Sistem ini juga dapat mempertahankan verified boot chain untuk partisi sistem operasi.
GrapheneOS tidak dapat menciptakan hardware interface yang didukung untuk menulis ulang IMEI perangkat produksi.
Di situlah batas intinya. Sistem operasi yang berorientasi privasi paling efektif ketika mengurangi akses yang tidak perlu ke state sensitif, mengisolasi software yang tidak dipercaya, dan mempertahankan integritas sistem yang dapat diverifikasi. Sistem tersebut bukan mekanisme untuk membuat setiap identitas hardware menjadi mutable.
Menyamakan dua kemampuan itu akan mengaburkan model keamanan yang sebenarnya. GrapheneOS melindungi sisi Android dari boundary dengan mengendalikan authority. Sisi modem tetap dibatasi oleh interface hardware dan firmware yang benar-benar disediakan perangkat.