Dompet identitas elektronik eIDAS Jerman memakai struktur verifikasi keamanan perangkat berbasis akun Apple dan Google

 (bmi.usercontent.opencode.de)
1 poin oleh GN⁺ 17 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • National EUDI Wallet Jerman menjaga integritas autentikasi identitas elektronik melalui kerangka manajemen kerentanan keamanan perangkat mobile (MDVM)
  • MDVM mendeteksi kerentanan pada sistem operasi dan hardware key store (HKS), lalu memblokir penggunaan kunci autentikasi bila risikonya tinggi
  • Di Android, verifikasi integritas perangkat memakai Google Play Integrity API dan KeyAttestation; di iOS memakai Apple DeviceCheck·AppAttest
  • Karena struktur ini, saat memakai fungsi identitas elektronik, prosedur verifikasi berbasis akun Apple atau Google wajib berjalan
  • Seluruh sistem dirancang untuk mencegah penyalinan dan penyalahgunaan kunci oleh penyerang serta mempertahankan autentikasi eID dengan tingkat jaminan tinggi

Konsep manajemen kerentanan perangkat mobile (Mobile Device Vulnerability Management, MDVM)

  • MDVM adalah kerangka dalam arsitektur National EUDI Wallet Jerman yang terus memantau kerentanan keamanan pada perangkat pengguna dan menjaga integritas sarana autentikasi
  • Mendeteksi kerentanan yang diketahui pada HKS (hardware key store) dan sistem operasi (OS), lalu memblokir penggunaan kunci RWSCA/RWSCD bila risiko serangan tinggi
  • Dengan ini, sistem mempertahankan tingkat jaminan tinggi dalam proses verifikasi identitas elektronik (eID) dan mencegah penyalinan serta penyalahgunaan kunci oleh penyerang
  • MDVM terdiri dari empat fungsi: verifikasi status keamanan perangkat dan aplikasi, identifikasi kelas perangkat, verifikasi kerentanan, dan keputusan penggunaan

Latar belakang

  • Wallet Unit menyediakan sarana autentikasi yang terhubung ke berbagai sarana identitas (seperti PID) melalui pasangan kunci publik/pribadi
  • Saat PID diterbitkan, WB (Wallet Backend) memverifikasi kepada PP (Provider Party) melalui OpenID4VCI Key Attestation bahwa kunci tersebut dikendalikan oleh sarana autentikasi dengan tingkat ketahanan terhadap serangan tertentu
  • Sesuai ISO/IEC 18045 dan regulasi EU 2015/1502, verifikasi identitas elektronik dengan tingkat jaminan tinggi memerlukan sarana autentikasi yang kuat
  • Sarana autentikasi memberikan dua jaminan
    1. Mencegah penyalinan dan manipulasi key store
    2. Mencegah serangan terhadap mekanisme autentikasi pengguna
  • Jaminan pertama dapat diwujudkan dengan RWSCD berbasis HSM, dan dicapai terlepas dari perangkat pengguna
  • Jaminan kedua bergantung pada keamanan perangkat pengguna, yang terdiri dari faktor kepemilikan (berbasis HKS) dan faktor pengetahuan (kata sandi, dsb.)
  • Pada HKS atau OS perangkat mobile, analisis dan sertifikasi kerentanan secara vooraf dalam praktik tidak memungkinkan, dan banyak kerentanan juga telah dilaporkan sebelumnya
  • Karena itu, sistem mengurangi kemungkinan serangan melalui kerangka pemantauan kerentanan saat operasional (MDVM), dan memblokir penggunaan kunci RWSCA/RWSCD pada perangkat dengan keamanan yang tidak memadai

Fungsi utama MDVM

Fungsi Penjelasan
Verifikasi status keamanan perangkat/aplikasi Memverifikasi integritas dan keaslian perangkat serta aplikasi Wallet, dengan memanfaatkan fitur keamanan platform dan RASP (Runtime Application Self-Protection)
Identifikasi kelas perangkat Mengidentifikasi model perangkat, versi OS dan tingkat patch, serta informasi HKS dengan cara yang terverifikasi
Verifikasi kerentanan per kelas perangkat Memeriksa informasi kerentanan terbaru pada OS dan HKS
Keputusan penggunaan perangkat/aplikasi Berdasarkan status keamanan dan informasi kerentanan, sistem memblokir verifikasi OpenID4VCI Key Attestation dan penggunaan kunci RWSCD pada perangkat dengan keamanan yang tidak memadai

Sinyal yang dikumpulkan

  • Sinyal yang dikumpulkan dipakai untuk respons ancaman, identifikasi kelas perangkat, dan plausibility check

  • Sumber sinyal utama: KeyAttestation, PlayIntegrity, DeviceCheck, RASP, LPADB, DCVDB

  • Ringkasan

    Sumber sinyal Ancaman yang ditangani Sinergi Catatan
    KeyAttestation Rooting, bootloader dibuka, ROM kustom, manipulasi aplikasi, cloning, emulasi, serangan replay, dll. LPADB, RASP Dipakai sebagai input DCVDB
    PlayIntegrity Manipulasi aplikasi, replay, rooting, ROM kustom, penilaian MDVM berbasis backend Google, alat pencurian kredensial, serangan overlay, dll. KeyAttestation, RASP Perlu verifikasi status bootloader
    iOS DeviceCheck Replay, manipulasi sertifikat, serangan proxy, manipulasi aplikasi RASP Jaminan integritas perangkat kurang kuat
    LPADB Penyembunyian rooting memakai kunci KeyAttestation yang telah dipublikasikan KeyAttestation -
    DCVDB Deteksi perangkat tidak aman berdasarkan kerentanan yang diketahui KeyAttestation, RASP Akurasi identifikasi kelas perangkat penting
    RASP Deteksi app hooking, debugging, rooting, emulasi - Pemantauan integritas berkelanjutan saat runtime

Sinyal Android KeyAttestation

  • Mengidentifikasi model perangkat, versi OS, tingkat patch, status bootloader, dll. melalui informasi verifikasi hardware berbasis HKS
  • Item sinyal utama
    • SecurityLevel: identifikasi jenis HKS (TrustedEnvironment, StrongBox)
    • attestationIdModel/Product/Device: identifikasi model perangkat
    • osVersion / osPatchLevel: versi OS dan tingkat patch keamanan
    • RootOfTrust: status bootloader dan Verified Boot
    • AttestationApplicationId: nama paket aplikasi, versi, hash sertifikat tanda tangan
  • Daftar pencabutan sertifikat Key-Attestation milik Google lambat diperbarui sehingga kunci yang bocor ke publik masih bisa dipakai
  • Pada sebagian perangkat, beberapa field identifikasi bisa hilang, sehingga ketiga field harus dievaluasi bersama

Sinyal Android PlayIntegrity Verdict

  • Memverifikasi integritas aplikasi dan perangkat melalui Google Play Integrity API
  • Item sinyal utama
    • appRecognitionVerdict: apakah aplikasi adalah versi asli
    • deviceRecognitionVerdict: tingkat kepercayaan perangkat (mis. MEETS_STRONG_INTEGRITY)
    • appLicensingVerdict: apakah terpasang melalui Play Store
    • playProtectVerdict: penilaian risiko Play Protect
  • MEETS_STRONG_INTEGRITY mensyaratkan patch keamanan diterapkan dalam 12 bulan terakhir
  • Untuk menjamin kepercayaan pada sinyal, diperlukan verifikasi tanda tangan dan dekripsi
  • Metode evaluasi internal backend Google tidak dipublikasikan

Android RASP

  • Solusi spesifik belum dipastikan dan masih pada tahap definisi kebutuhan fungsional
  • Fungsi deteksi
    • App Hooking/Debugging: deteksi manipulasi dinamis (Frida, Xposed, dll.)
    • App Repackaging/Tampering: deteksi manipulasi aplikasi dan penandatanganan ulang
    • UD Rooting/Emulation: deteksi rooting, virtualisasi, dan lingkungan otomatisasi
  • RASP menyediakan pemantauan integritas saat runtime, dan menjaga blocklist terpisah dari daftar pencabutan Google untuk mencegah serangan berbasis kunci yang bocor

iOS DCDeviceCheck.AppAttest Attestation

  • Struktur autentikasi aplikasi melalui Secure Enclave dan server Apple
  • Sinyal utama
    • attestationObject: membuktikan bahwa kunci App Attest dibuat di Secure Enclave
    • credentialId: pengenal kunci App Attest
    • RP ID: App ID prefix + Bundle ID aplikasi
  • Indikator risiko Apple (receipt metric) dapat dipakai untuk mendeteksi serangan proxy, tetapi tidak memiliki kriteria yang jelas dan ada risiko paparan privasi akibat komunikasi dengan server Apple
  • Di iOS, informasi berbasis hardware untuk model perangkat, versi OS/tingkat patch tidak dapat disediakan, sehingga hanya bisa diperiksa lewat query OS

iOS DCDeviceCheck.AppAttest Assertions

  • Struktur verifikasi berbasis tanda tangan yang dibuat dengan kunci App Attest
  • Sinyal utama
    • assertionObject: mencakup tanda tangan untuk challenge
    • keyId: pengenal kunci App Attest
    • counter: jumlah penandatanganan, harus meningkat secara monoton
  • Lonjakan tajam nilai counter mengindikasikan kemungkinan serangan proxy, sedangkan penurunan mengindikasikan kemungkinan serangan replay

iOS RASP

  • Memerlukan fungsi deteksi yang mirip dengan Android
    • App Hooking/Debugging, App Repackaging, App Tampering, UD Rooting, UD Emulation
  • App Sandbox, Code Signing, dan System Integrity Protection milik Apple hanya memberi perlindungan pada tahap instalasi, dan tidak memiliki fungsi deteksi rooting, hooking, atau manipulasi runtime
  • RASP melengkapi hal ini lewat pemantauan integritas saat runtime
  • Menurut dokumentasi Apple, App Attest menyatakan bahwa “aplikasi yang telah dimanipulasi dan berjalan di perangkat normal tidak dapat menghasilkan assertion yang valid”

Kesimpulan

  • MDVM mengevaluasi status keamanan perangkat secara real-time dan memblokir penggunaan kunci autentikasi di lingkungan dengan kemungkinan serangan tinggi, sehingga menjaga keandalan sistem autentikasi identitas elektronik
  • Baik Android maupun iOS membangun kerangka verifikasi integritas perangkat dengan menggabungkan fitur keamanan platform dan perlindungan dinamis berbasis RASP
  • Terdapat ketergantungan pada sistem verifikasi backend Google dan Apple, dan metode evaluasi internal yang tidak dipublikasikan tetap menjadi faktor ketidakpastian potensial

Bacaan terkait

1 komentar

 
GN⁺ 17 hari lalu
Komentar Hacker News

  • Spesifikasi eIDAS 2.0 tidak mewajibkan perangkat keras tertentu
    Ini hanya struktur untuk menyimpan kredensial yang dapat diverifikasi dan sertifikat yang ditandatangani secara kriptografis
    Tampaknya seperti bentuk kemalasan dari tim implementasi Jerman yang ingin menghindari klausul bahwa “pengguna harus dapat memverifikasi keaslian Wallet Unit”
    Dokumen terkait dapat dilihat di EUDI Architecture and Reference Framework

    • Jika melihat implementasi referensi, para maintainer tampaknya tidak ingin menghapus ketergantungan pada Google
      Alasannya tidak jelas, tetapi jika sesuatu terus dipertahankan tanpa alasan, biasanya justru ada alasan
      Lihat repositori GitHub
    • Jika melihat bagian 5.4 tentang Attestation Rulebooks dan Attestation Schemes, aturan terkait dijelaskan di sana

  • Sebagai implementator di Jerman, sesuai peraturan pelaksana eIDAS, kami memang harus menggunakan mekanisme attestation
    Ini tidak akan berfungsi tanpa dukungan dari sistem operasi
    Kami tahu bahwa pembatasan saat ini pada Google/Android bukanlah kondisi ideal, dan dukungan untuk OS lain seperti GrapheneOS juga direncanakan
    Saat ini ini hanya soal prioritas, bukan karena kami tidak menyadari masalahnya

    • Bergantung pada produk dari dua perusahaan AS bukan sekadar “kurang baik”, tetapi masalah serius
      Kasus akun terkunci sangat banyak, dan ketergantungan seperti ini sebaiknya memang tidak ada
    • Ada juga unsur ilegal dari sisi aksesibilitas dan pelanggaran terhadap semangat eIDAS
      Pada akhirnya semua warga menjadi tunduk pada syarat dan ketentuan Google·Apple, dan jika akun ditangguhkan maka akses ke layanan eID menjadi tidak mungkin
      Karena secara teknis ada alternatif, maka mencari solusi seperti itu adalah tanggung jawab Anda
    • Sebagai warga Jerman, saya ingin bertanya: mengapa tetap dilanjutkan jika sudah tahu ini tidak akan bekerja untuk semua warga?
      Saya pindah dari Android berbasis AOSP tanpa Google Play ke Ubuntu Touch, dan ke depan berencana beralih ke postmarketOS
    • Sangat mudah kehilangan akses ke akun Google. Pemulihannya juga tidak mungkin
      Jika mempertimbangkan situasi ini dan risiko geopolitik, ketergantungan pada perusahaan tertentu tidak bisa dibenarkan
      Ada juga pelajaran dari pengalaman para pengembang bahwa “solusi sementara adalah solusi yang paling permanen”
    • Mengapa masalah yang sebenarnya sudah diselesaikan oleh Mobile-ID eIDAS 1 (berbasis SIM) atau Smart-ID (manajemen kunci di sisi server)
      harus diubah paksa menjadi model Wallet? Tidak ada alasan untuk bergantung pada backend dua perusahaan AS

  • Attestation itu sendiri seharusnya dihapus
    Aplikasi seharusnya tidak boleh mengetahui dijalankan di perangkat apa
    Pengguna cukup melindungi perangkatnya sendiri, dan pengembang cukup memberikan rekomendasi
    Ini harus bisa berjalan di lingkungan apa pun, termasuk GrapheneOS, perangkat yang di-root, emulator, atau lapisan kompatibilitas Linux

    • Benar, ini perangkat saya, jadi saya harus bisa menggunakannya sesuka saya
      Tidak perlu aplikasi otomatis memeriksa apakah sudah “disertifikasi” oleh big tech AS
    • Konsep kepercayaan perangkat sendiri adalah ilusi
      Jika melihat sejarah konsol dan ponsel yang di-root, tidak ada keamanan yang sempurna
      Akan lebih baik jika pengguna bisa memilih untuk mengikat identitasnya ke perangkat sebagai opsi pilihan
    • Tentu saja rooting atau modifikasi itu bebas dilakukan, tetapi konsekuensinya juga harus diterima
      Jika aplikasi tidak bisa memverifikasi integritasnya sendiri, maka sebagian fungsi menjadi tidak mungkin secara keamanan
      Seperti kartu identitas fisik yang juga punya batasan bentuk atau ukuran, beberapa pembatasan tetap diperlukan
    • Dosa asal komputasi modern adalah bahwa ‘elemen keamanan’ dirancang untuk produsen, bukan untuk pengguna
      Masalah ini bermula ketika pada era NGSCB elemen seperti ini tidak dilarang secara hukum

  • Bagaimana jika kehilangan akun Google/Apple?
    Jika seseorang dikenai sanksi seperti hakim Mahkamah Pidana Internasional, akses ke eIDAS bisa menjadi tidak mungkin
    Fakta bahwa masyarakat Eropa masih mempertahankan struktur yang bergantung pada perusahaan AS adalah realitas yang kontradiktif

    • Bahkan tanpa menjadi tokoh terkenal, penangguhan akun otomatis bisa membuat seseorang tersisih secara sosial
      Berbahaya jika dua perusahaan asing memiliki kewenangan pengawasan dan kontrol seperti itu
    • “Kalau ibu kota Eropa ada di Washington”, mungkin hal seperti ini terasa wajar
    • Berarti naik Waymo juga jadi tidak bisa

  • Mengejutkan bahwa penolakan publik terhadap kebijakan seperti ini begitu kecil
    Sebagai orang tua, saya paham perlunya mengendalikan penggunaan internet anak-anak,
    tetapi pada akhirnya negara mengambil alih tugas yang seharusnya dilakukan orang tua dan kita kehilangan kebebasan dan privasi

    • Kebanyakan orang hanya memahami secara abstrak bagaimana ini memengaruhi hidup mereka
      Kalau bukan ancaman yang konkret seperti “pemerintah membaca pesan WhatsApp saya”, mereka tidak akan bereaksi
    • Di Jerman, perhatian terpecah oleh isu-isu tidak produktif seperti perdebatan batas kecepatan
      Kalangan politik memanfaatkan kekacauan seperti ini untuk menutupi masalah yang esensial
    • Justru banyak orang tua mendukung pembatasan akses online
      Mereka ingin anak-anak terlindungi dari eksploitasi perhatian oleh perusahaan raksasa
      Seperti di dunia nyata ada batas usia, dunia online juga tidak harus menjadi pengecualian
    • Orang-orang terjebak dalam filter bubble mereka sendiri sehingga bahkan tidak mendengar isu seperti ini
      Jika memikirkan masa depan demokrasi, ini sangat mengkhawatirkan
    • Uni Eropa pada dasarnya berfungsi sebagai platform lobi
      Lobi warga memang mungkin, tetapi butuh biaya dan koordinasi sehingga perusahaan besar yang memimpin
      Baru-baru ini juga ada insiden infrastruktur digital EU dibobol kelompok peretas
      Artikel terkait

  • Persyaratan perangkat keras·perangkat lunak tertentu itu tidak rasional
    Semua warga harus bisa memakai komputer yang mereka inginkan
    Autentikasi cukup dengan kata sandi atau pasangan kunci, dan jika mau bisa ditambah TOTP atau security key
    Seolah-olah mereka lupa bahwa komputer selain smartphone juga ada

    • Uni Eropa katanya ingin membuat sistem pembayaran independen dari VISA·MasterCard, tetapi pada akhirnya tetap bergantung pada app store
      Tanpa akun Apple·Google, pembayaran euro digital pun menjadi tidak mungkin
      Mengejutkan bahwa politisi dan bank tidak bisa melihat dua atau tiga langkah ke depan
    • Kebijakan Uni Eropa bergerak bukan ke arah “penilaian risiko mandiri oleh pengguna”,
      melainkan ke arah penyedia layanan harus melindungi pengguna
      Akibatnya, pembatasan platform yang didukung menjadi tidak terhindarkan
    • Pernyataan “harus bisa berjalan di semua komputer” juga tidak realistis
      Itu bukan berarti secara hukum harus bisa berjalan di Apple II juga

  • Pihak yang terkena sanksi atau kelompok tertentu tidak bisa mengakses Play Store,
    sehingga pemasangan aplikasi eIDAS itu sendiri bisa menjadi tidak mungkin

    • Jika memang butuh akun, ya begitu jadinya
      Melihat kasus penghapusan akun lawan politik belakangan ini, bagi sebagian otoritas itu mungkin malah dianggap hal yang menguntungkan
    • Tetapi perlindungan kunci privat adalah inti masalahnya
      Diperlukan perangkat keamanan seperti smart card, sehingga lingkungan yang sepenuhnya terbuka memang berisiko
      Keinginan untuk “memakai Android alternatif” bisa dipahami, tetapi itu harus dipahami sebagai lingkungan yang tidak aman

  • Saya penasaran berapa banyak anggaran yang akan dibuang Uni Eropa untuk sistem seperti ini
    Saya benar-benar tidak tahu siapa yang sebenarnya membutuhkan ini

  • Hanya Self Sovereign Identity (SSI) yang merupakan solusi sejati
    Identitas pribadi tidak boleh bergantung pada institusi atau perusahaan mana pun
    Identitas seharusnya hanyalah ‘diri saya sendiri’
    Yang dibutuhkan bukan Google ID atau Apple ID, melainkan identitas berdaulat mandiri

    • Tetapi “saya ya saya” bukanlah verifikasi identitas yang realistis
      Di bar Anda tidak bisa mengatakan itu sebagai ganti menunjukkan kartu identitas
      Dalam kontrak sosial, verifikasi identitas yang fungsional tetap diperlukan
    • Uni Eropa sebenarnya sudah membuat ESSIF (European Self-Sovereign Identity Framework) pada 2019
      Infrastruktur itu sudah ada sejak 7 tahun lalu, jadi pemerintah tidak bisa semata-mata disebut tidak kompeten

  • Rasanya sudah waktunya terjadi “insiden pembakaran Reichstag versi digital”
    Saya ingin bertanya kapan Jerman akan berhenti mengulangi kebiasaan sejarah