Android Uygulamalarda Keystore
Android Uygulamalarda Keystore Yanlış Kullanımı: Sahte Güvenlik Algısı ve Gerçek RisklerMobil uygulama güvenliği alanında geliştiricilerin en sık düştüğü hatalardan biri, bir güvenlik mekanizmasını kullanmanın onu doğru kullandıkları anlamına geldiğini düşünmeleridir. Android Keystore bu hatanın en net örneklerinden biridir. Birçok uygulama, hassas verileri Keystore içine alarak güvenliği sağladığını varsayar; ancak gerçek dünyada yapılan testler, yanlış yapılandırılmış Keystore kullanımının saldırganlar için ciddi fırsatlar sunduğunu göstermektedir.
Bu makalede Android Keystore’un nasıl çalıştığı anlatılmayacak; bunun yerine neden tek başına güvenli olmadığı, hangi hataların gerçek zafiyetlere dönüştüğü, saldırganların bu zayıflıkları nasıl istismar ettiği ve pentest sırasında bu hataların nasıl tespit edildiği detaylı biçimde ele alınacaktır.
Keystore Kullanmak Neden Güvenliği Garanti Etmez?
Android Keystore’un temel vaadi şudur:
Kriptografik anahtarlar uygulama dışına çıkarılamaz ve mümkünse donanım destekli güvenli alanlarda saklanır.
Bu doğru. Ancak kritik nokta şudur:
Saldırganların hedefi çoğu zaman anahtarın kendisi değildir.
Gerçek saldırılar şunları hedef alır:
Anahtar kullanılarak üretilen token’lar
Şifreleme öncesi plaintext veriler
İmzalama işlemlerinin çıktıları
Keystore API’lerinin runtime davranışı
Dolayısıyla Keystore, yalnızca tasarım doğruysa anlamlıdır. Yanlış tasarımda, sadece geciktirici bir unsur olur.
En Yaygın ve En Tehlikeli Keystore Hataları
1. Hardware-Backed Anahtar Zorunluluğunun Belirtilmemesi
Birçok uygulama anahtar üretirken şu kontrolü yapmaz:
Anahtar gerçekten TEE (Trusted Execution Environment) içinde mi?
Yoksa software-backed olarak mı tutuluyor?
Bu kontrol yapılmadığında:
Emulator
Root’lu cihaz
Custom ROM
ortamlarında anahtar davranışı değişir. Bu da aynı uygulamanın farklı cihazlarda farklı güvenlik seviyelerinde çalışması anlamına gelir.
Bu durum özellikle:
Finans uygulamaları
Kurumsal mobil çözümler
Offline veri şifreleyen uygulamalar
için kritik bir mimari hatadır.
2. Kullanıcı Doğrulamasının (Biometric / Credential) Atlanması
Doğru bir Keystore tasarımında, anahtar kullanımı şu koşullara bağlanmalıdır:
Parmak izi
Yüz tanıma
Cihaz kilidi
Zaman aşımı (timeout)
Ancak pratikte:
setUserAuthenticationRequired(false)veya hiç tanımlanmamış authentication parametreleri
sıklıkla görülür.
Sonuç olarak:
Uygulama arka planda çalışırken
Kullanıcı ekran kilitliyken
Fiziksel erişim olmadan
kriptografik işlemler yapılabilir. Bu durum, token üretimi ve API yetkilendirme süreçlerini tamamen anlamsız hale getirir.
3. Anahtarın Birden Fazla Amaçla Kullanılması (Key Reuse)
Kriptografi dünyasında key reuse ciddi bir tasarım kusurudur. Buna rağmen mobil uygulamalarda sıkça görülür.
Örnek senaryo:
Aynı Keystore anahtarı ile:
Dosya şifreleme
Kullanıcı token’ı koruma
API request imzalama
yapılması.
Bu tasarımda tek bir zayıflık:
Tüm veri gizliliğini
Tüm iletişim güvenliğini
Tüm yetkilendirme mekanizmasını
çökertir. Bu hata genellikle kod incelemesi sırasında fark edilmez, ancak dinamik analizde net biçimde ortaya çıkar.
Runtime Kriptografi Hook’lama
Keystore anahtarları export edilemez, evet.
Ama şu fonksiyonlar export edilebilir çıktılar üretir:
Cipher.doFinal()Signature.sign()Mac.doFinal()
Frida veya Xposed kullanılarak bu fonksiyonlar hook edildiğinde:
Şifreleme öncesi veri
Şifreleme sonrası veri
İmzalanan payload
elde edilebilir.
Bu noktada Keystore’un donanım destekli olması hiçbir fark yaratmaz. Çünkü saldırı anahtarı değil, anahtarın kullanımını hedef alır.
Bu saldırı türü özellikle:
Offline çalışan uygulamalar
Token cache kullanan sistemler
API request imzalama yapan mobil istemciler
için yüksek risklidir.
Pentest Perspektifinden Keystore Zafiyetleri Nasıl Tespit Edilir?
1. Statik Analiz
APK veya source code incelenirken şu noktalar aranır:
KeyGenParameterSpecyapılandırmalarıAuthentication flag’leri
StrongBox kullanım durumu
Aynı alias ile üretilmiş çok amaçlı anahtarlar
Bu aşama genellikle zafiyetin %60’ını ortaya çıkarır.
2. Dinamik Analiz
Runtime testlerde:
Kriptografik API’ler hook edilir
Anahtar davranışı izlenir
Root / emulator farkları test edilir
Eğer uygulama farklı ortamlarda farklı sonuçlar üretiyorsa, bu gizli ama kritik bir zafiyet göstergesidir.
3. Davranışsal Güvenlik Testi
Uygulama:
Arka planda çalışırken
Ekran kilitliyken
Kullanıcı logout durumundayken
kriptografik işlem yapabiliyor mu?
Evet ise, Keystore yanlış yapılandırılmıştır.
Doğru Keystore Tasarımı İçin Zorunlu Prensipler
Her anahtar tek amaçlı olmalı
Hardware-backed anahtar zorunlu tutulmalı
Kullanıcı doğrulaması olmadan işlem yapılamamalı
Runtime hook tespiti eklenmeli
Kriptografik çıktılar minimum süre bellekte tutulmalı
Bu önlemler alınmadığında Keystore, gerçek güvenlik değil, sadece psikolojik bir rahatlama sağlar.
Android Developers – Keystore
📎 https://developer.android.com/privacy-and-security/keystoreOWASP Mobile Top 10
📎 https://owasp.org/www-project-mobile-top-10/ bu kaynaklardan da yararlanabilirsiniz ve Mobil CVE Zafiyetleri yapılan araştırmayı da okuyabilirsiniz.













