Android Uygulamalarda Keystore

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:

  • KeyGenParameterSpec yapı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.

About The Author

Reply