Almanya eIDAS elektronik kimlik cüzdanında Apple·Google hesap tabanlı cihaz güvenliği doğrulama yapısı
(bmi.usercontent.opencode.de)- Almanya’nın National EUDI Wallet sistemi, mobil cihazların güvenlik zafiyeti yönetimi (MDVM) yapısı üzerinden elektronik kimlik doğrulamasının bütünlüğünü korur
- MDVM, işletim sistemi ve donanım anahtar deposu (HKS) zafiyetlerini tespit eder ve risk yüksekse doğrulama anahtarlarının kullanımını engeller
- Android’de Google Play Integrity API ve KeyAttestation, iOS’ta ise Apple DeviceCheck·AppAttest kullanılarak cihaz bütünlüğü doğrulanır
- Bu yapı nedeniyle elektronik kimlik işlevi kullanılırken Apple veya Google hesap tabanlı doğrulama süreci zorunlu olarak devreye girer
- Tüm sistem, saldırganların anahtar kopyalaması·kötüye kullanmasını önlemeyi ve yüksek güvence seviyesinde eID doğrulamasını sürdürmeyi hedefleyecek şekilde tasarlanmıştır
Mobil cihaz zafiyeti yönetimi kavramı (Mobile Device Vulnerability Management, MDVM)
- MDVM, Almanya’nın National EUDI Wallet mimarisi içinde kullanıcı cihazının güvenlik zafiyetlerini sürekli izleyen ve doğrulama araçlarının bütünlüğünü koruyan bir yapıdır
- HKS(donanım anahtar deposu) ve işletim sistemi (OS) üzerindeki bilinen zafiyetleri tespit ederek, saldırı riski yüksekse RWSCA/RWSCD anahtarlarının kullanımını engeller
- Böylece elektronik kimlik doğrulama (eID) sürecinde yüksek güvence seviyesi korunur ve saldırganların anahtar kopyalaması·kötüye kullanması önlenir
- MDVM; cihaz ve uygulamanın güvenlik durumunun doğrulanması, cihaz sınıfının belirlenmesi, zafiyet doğrulaması ve kullanım kararı olmak üzere dört işlevden oluşur
Gerekçe
- Wallet Unit, açık/gizli anahtar çifti üzerinden çeşitli kimlik araçlarına (PID vb.) bağlanan doğrulama aracı sağlar
- PID verilirken WB(Wallet Backend), söz konusu anahtarın belirli düzeyde saldırı direncine sahip bir doğrulama aracı tarafından kontrol edildiğini OpenID4VCI Key Attestation ile PP(Provider Party) için doğrular
- ISO/IEC 18045 ve AB düzenlemesi 2015/1502 uyarınca, yüksek güvence seviyesinde elektronik kimlik doğrulaması için güçlü doğrulama araçları gerekir
- Doğrulama aracı iki güvence sağlar
- Anahtar deposunun kopyalanmasını ve kurcalanmasını önleme
- Kullanıcı doğrulama mekanizmasına yönelik saldırıları önleme
- İlk güvence, HSM tabanlı RWSCD ile gerçekleştirilebilir ve kullanıcı cihazından bağımsız olarak sağlanabilir
- İkinci güvence ise kullanıcı cihazı güvenliğine bağlıdır ve sahiplik unsuru (HKS tabanlı) ile bilgi unsuru (parola vb.) bileşenlerinden oluşur
- Mobil cihazların HKS ya da OS bileşenleri için önceden zafiyet analizi ve sertifikasyon yapmak pratikte mümkün değildir; geçmişte de çok sayıda zafiyet bildirilmiştir
- Bu nedenle çalışma sırasındaki zafiyet izleme yapısı (MDVM) ile saldırı olasılığı azaltılır ve güvenliği yetersiz cihazlarda RWSCA/RWSCD anahtarlarının kullanımı engellenir
MDVM’in temel işlevleri
| İşlev | Açıklama |
|---|---|
| Cihaz/uygulama güvenlik durumunun doğrulanması | Cihaz ve Wallet uygulamasının bütünlüğü ile gerçekliğini doğrular; platform güvenlik özellikleri ve RASP(Runtime Application Self-Protection) kullanılır |
| Cihaz sınıfının belirlenmesi | Cihaz modeli, OS sürümü ve yama seviyesi ile HKS bilgilerini doğrulanmış biçimde belirler |
| Cihaz sınıfına göre zafiyet doğrulaması | OS ve HKS için en güncel zafiyet bilgilerini kontrol eder |
| Cihaz/uygulama kullanım kararı | Güvenlik durumu ve zafiyet bilgilerine dayanarak, güvenliği yetersiz cihazlarda OpenID4VCI Key Attestation doğrulamasını ve RWSCD anahtar kullanımını engeller |
Toplanan sinyaller
-
Toplanan sinyaller tehditlere karşı koyma, cihaz sınıfı belirleme ve makullük kontrolü (plausibility check) için kullanılır
-
Başlıca sinyal kaynakları: KeyAttestation, PlayIntegrity, DeviceCheck, RASP, LPADB, DCVDB
-
Genel bakış
Sinyal kaynağı Karşılanan tehdit Sinerji Not KeyAttestation Root, bootloader kilidinin açılması, custom ROM, uygulama kurcalama, kopyalama, emülasyon, replay saldırıları vb. LPADB, RASP DCVDB girdisi olarak kullanılır PlayIntegrity Uygulama kurcalama, replay, root, custom ROM, Google backend tabanlı MDVM kararı, kimlik bilgisi çalma araçları, overlay saldırıları vb. KeyAttestation, RASP Bootloader durumunun doğrulanması gerekir iOS DeviceCheck Replay, sertifika kurcalama, proxy saldırıları, uygulama kurcalama RASP Cihaz bütünlüğü güvencesi yetersiz LPADB Açık şekilde yayımlanmış KeyAttestation anahtarlarıyla root gizleme KeyAttestation - DCVDB Bilinen zafiyetlere dayanarak güvensiz cihaz tespiti KeyAttestation, RASP Cihaz sınıfı belirlemede doğruluk önemlidir RASP Uygulama hooking, debugging, root, emülasyon tespiti - Çalışma sırasında bütünlüğü sürekli izler
Android KeyAttestation sinyalleri
- HKS tabanlı donanım doğrulama bilgileri ile cihaz modeli, OS sürümü, yama seviyesi, bootloader durumu vb. belirlenir
- Başlıca sinyal alanları
- SecurityLevel: HKS türünü belirleme (TrustedEnvironment, StrongBox)
- attestationIdModel/Product/Device: cihaz modeli belirleme
- osVersion / osPatchLevel: OS sürümü ve güvenlik yaması seviyesi
- RootOfTrust: bootloader ve Verified Boot durumu
- AttestationApplicationId: uygulama paket adı, sürüm, imza sertifikası hash’i
- Google’ın Key-Attestation sertifika iptal listesi yavaş güncellendiği için kamuya sızmış anahtarlar hâlâ kullanılabiliyor
- Bazı cihazlarda belirli tanımlayıcı alanlar eksik olabileceğinden üç alanın da birlikte değerlendirilmesi gerekir
Android PlayIntegrity Verdict sinyalleri
- Google Play Integrity API üzerinden uygulama ve cihaz bütünlüğü doğrulanır
- Başlıca sinyal alanları
- appRecognitionVerdict: uygulamanın orijinal olup olmadığı
- deviceRecognitionVerdict: cihaz güven seviyesi (ör. MEETS_STRONG_INTEGRITY)
- appLicensingVerdict: Play Store üzerinden kurulup kurulmadığı
- playProtectVerdict: Play Protect risk değerlendirmesi
- MEETS_STRONG_INTEGRITY, son 12 ay içinde güvenlik yamasının uygulanmış olmasını gerektirir
- Sinyal güvenilirliğini sağlamak için imza doğrulaması ve şifre çözme gerekir
- Google backend’inin iç değerlendirme yöntemi kamuya açık değildir
Android RASP
- Somut çözüm henüz kesinleşmemiştir; gereksinim işlevleri tanımlama aşamasındadır
- Tespit işlevleri
- App Hooking/Debugging: dinamik manipülasyon tespiti (Frida, Xposed vb.)
- App Repackaging/Tampering: uygulama değiştirme ve yeniden imzalama tespiti
- UD Rooting/Emulation: root, sanallaştırma, otomasyon ortamı tespiti
- RASP, çalışma sırasında bütünlük izleme sağlar ve Google’ın iptal listesinden ayrı bir blok listesi tutarak sızmış anahtarlara dayalı saldırıları önler
iOS DCDeviceCheck.AppAttest Attestation
- Secure Enclave ve Apple sunucuları üzerinden çalışan uygulama doğrulama yapısı
- Başlıca sinyaller
- attestationObject: App Attest anahtarının Secure Enclave içinde üretildiğini kanıtlar
- credentialId: App Attest anahtar tanımlayıcısı
- RP ID: uygulamanın App ID prefix + Bundle ID değeri
- Apple’ın risk göstergesi (receipt metric) proxy saldırılarının tespitinde kullanılabilir; ancak net ölçütlerin olmaması ve Apple sunucularıyla iletişim nedeniyle kişisel veri sızıntısı riski vardır
- iOS, cihaz modeli ile OS sürümü/yama seviyesi için donanım tabanlı bilgi sağlayamaz; bunlar yalnızca OS sorgusuyla doğrulanabilir
iOS DCDeviceCheck.AppAttest Assertions
- App Attest anahtarı ile oluşturulan imza tabanlı doğrulama yapısı
- Başlıca sinyaller
- assertionObject: challenge’a ilişkin imzayı içerir
- keyId: App Attest anahtar tanımlayıcısı
- counter: imzalama sayısı; tek yönlü artması gerekir
- Sayaç değerindeki ani artış proxy saldırısı olasılığına, azalma ise replay saldırısı olasılığına işaret eder
iOS RASP
- Android’e benzer tespit işlevleri gerekir
- App Hooking/Debugging, App Repackaging, App Tampering, UD Rooting, UD Emulation
- Apple’ın App Sandbox, Code Signing ve System Integrity Protection mekanizmaları yalnızca kurulum anında koruma sağlar; root·hooking·çalışma zamanı manipülasyonu tespiti sunmaz
- RASP, çalışma sırasındaki bütünlük izleme ile bunu tamamlar
- Apple belgelerine göre App Attest, “normal bir cihazda çalışan kurcalanmış bir uygulama geçerli bir assertion üretemez”
Sonuç
- MDVM, cihaz güvenlik durumunu gerçek zamanlı değerlendirip saldırı olasılığı yüksek ortamlarda doğrulama anahtarlarının kullanımını engelleyerek elektronik kimlik doğrulama sisteminin güvenilirliğini korur
- Hem Android hem iOS, platform güvenlik özellikleri ile RASP tabanlı dinamik korumayı birleştirerek cihaz bütünlüğü doğrulama yapısı oluşturur
- Google ve Apple’ın backend doğrulama sistemlerine bağımlılık söz konusudur ve kamuya açıklanmayan iç değerlendirme yöntemleri potansiyel bir belirsizlik unsuru olarak kalır
1 yorum
Hacker News görüşleri
eIDAS 2.0 spesifikasyonu belirli bir donanım gerektirmiyor
Yalnızca doğrulanabilir kimlik bilgileri ile kriptografik olarak imzalanmış sertifikaları depolayan bir yapı
Alman uygulama ekibinin, “kullanıcının Wallet Unit’in gerçekliğini doğrulayabilmesini sağlayan bir mekanizma uygulanmalıdır” maddesini aşmaya çalışma tembelliği gibi görünüyor
İlgili belgeler EUDI Architecture and Reference Framework içinde görülebilir
Sebebi net değil ama sebepsiz yere sürüyorsa, sonuçta bir sebebi vardır
GitHub deposuna bakın
Bir Alman geliştirici olarak, eIDAS uygulama yönetmeliği gereği attestation mekanizması kullanmak zorundayız
Bu, işletim sistemi desteği olmadan çalışmaz
Şu anda Google/Android ile sınırlı olmasının en iyi seçenek olmadığını biliyoruz ve GrapheneOS gibi diğer işletim sistemleri için destek de planlanıyor
Bu sadece şu an için bir öncelik meselesi; sorunun farkında olmamak değil
Hesap kilitlenmesi örnekleri çok fazla ve böyle bir bağımlılık kurmamak daha iyi olur
Sonuçta tüm vatandaşlar Google ve Apple’ın şartlarına tabi oluyor ve hesap askıya alınırsa eID hizmetine erişim imkânsız hale geliyor
Teknik olarak alternatifler bulunduğuna göre, böyle bir çözüm bulmak sizin sorumluluğunuz
Ben Google Play olmayan AOSP tabanlı Android’den Ubuntu Touch’a geçtim, ileride de postmarketOS’a geçmeyi planlıyorum
Bu durum ve jeopolitik riskler düşünülünce, belirli şirketlere bağımlılık haklı gösterilemez
“Geçici çözüm en kalıcı çözümdür” sözü de geliştirici tecrübesinin bir dersi
neden özellikle Wallet modeline çevirdiklerini merak ediyorum. İki Amerikan şirketinin arka uçlarına bağımlı olmak için bir neden yok
attestation’ın kendisi kaldırılmalı
Uygulama hangi cihazda çalıştığını bilmemeli
Kullanıcı kendi cihazını kendisi korur, geliştirici de yalnızca tavsiyelerde bulunur; bu yeterli
GrapheneOS, root, emülatör, Linux uyumluluk katmanı gibi her türlü ortamda çalışabilmeli
Uygulamanın ABD’li büyük teknoloji şirketlerinin “onayı” olup olmadığını otomatik kontrol etmesi gereksiz
Root’lu konsolların ve telefonların tarihine bakınca hiçbir güvenlik kusursuz değil
Kullanıcı isterse kimliğini cihazına bağlayabilmeli ama bunun isteğe bağlı bir seçenek olması daha doğru
Uygulama kendi bütünlüğünü doğrulayamazsa bazı işlevler güvenlik açısından imkânsız hale gelir
Fiziksel kimlik belgelerinde de şekil ya da boyut gibi sınırlamalar olduğu için belli kısıtlar gereklidir
NGSCB döneminde bu tür unsurların hukuken yasaklanmamış olması sorunun başlangıcıydı
Ya Google/Apple hesaplarını kaybederlerse?
Uluslararası Ceza Mahkemesi yargıçları gibi yaptırım listesine girerlerse eIDAS erişimi mümkün olmayacak
Avrupa toplumunun hâlâ ABD şirketlerine bağımlı bir yapı sürdürmesi çelişkili bir gerçeklik
İki yabancı şirketin gözetim ve kontrol yetkisine sahip olması tehlikeli
Bu tür politikalara karşı kamusal tepkinin az olması şaşırtıcı
Bir ebeveyn olarak çocukların internet kullanımını denetleme ihtiyacını anlıyorum ama
sonuçta ebeveynlerin yapması gerekeni devlet üstleniyor ve özgürlük ile mahremiyet kaybediliyor
“Hükümet WhatsApp mesajlarımı okuyor” gibi somut bir tehdit olmadıkça tepki vermiyorlar
Siyaset kurumu da bu karmaşadan yararlanarak esas meseleleri örtüyor
Çocukların büyük şirketlerin dikkat sömürüsünden korunmasını istiyorlar
Gerçek dünyada yaş sınırları olduğu gibi çevrim içi dünyada da istisna olmak zorunda değil
Demokrasinin geleceği açısından bu çok kaygı verici
Vatandaş lobiciliği mümkün ama maliyet ve koordinasyon gerektirdiğinden büyük şirketler öne çıkıyor
Kısa süre önce AB dijital altyapısının bir hacker grubu tarafından ihlal edildiği olay da vardı
İlgili haber
Belirli donanım ve yazılım şartları mantıksız
Tüm vatandaşlar istedikleri bilgisayarı kullanabilmeli
Kimlik doğrulama için parola ya da anahtar çifti yeterlidir; isteyen TOTP veya güvenlik anahtarı ekleyebilir
Akıllı telefon dışında bilgisayarların da var olduğu unutulmuş gibi
Apple ya da Google hesabı olmadan dijital euro ödemesi de mümkün olmayacak
Siyasetçilerin ve bankaların iki üç adım sonrasını görememesi şaşırtıcı
hizmet sağlayıcının kullanıcıyı koruması gerektiği yönünde ilerliyor
Bunun sonucu olarak desteklenen platformların sınırlandırılması kaçınılmaz hale geliyor
Bunun yasal olarak Apple II’de de çalışması gerektiği anlamına gelmediği açık
Yaptırım altındaki kişiler ya da belirli gruplar Play Store’a erişemediği için
eIDAS uygulamasını kurmaları baştan imkânsız olabilir
Son dönemdeki siyasi muhalif hesaplarının silinmesi örneklerine bakılırsa, bazı makamlar için bu hatta memnuniyet verici bile olabilir
Akıllı kart gibi bir güvenli cihaz gerekiyor, bu yüzden tamamen açık ortamlar riskli
“Alternatif Android kullanmak istiyorum” demenizi anlıyorum ama bunun güvensiz bir ortam olduğunu da kabul etmek gerekir
AB’nin bu tür sistemlere ne kadar bütçe israf edeceğini merak ediyorum
Bunu gerçekten kimin ihtiyaç duyduğu da belirsiz
Self Sovereign Identity(SSI) tek gerçek çözüm
Bir kişinin kimliği herhangi bir kurum ya da şirkete bağımlı olmamalı
Kimlik sadece ‘ben’ olmalı
Google ID ya da Apple ID değil, öz-egemen kimlik gerekli
Barda kimlik yerine bunu söyleyemezsiniz
Toplumsal sözleşme içinde işlevsel kimlik doğrulaması gereklidir
Altyapı yedi yıldır var olduğuna göre, her şeyi yalnızca devletin beceriksizliğine bağlamak doğru olmaz
Görünüşe göre “dijital bir Reichstag yangını” yaşanmasının zamanı gelmiş
Almanya’nın tarihini tekrarlama alışkanlığını ne zaman bırakacağını merak ediyorum