Neden Bu Konu Teknik Servis Uzmanları İçin Kritik?

Akıllı telefonlar artık salt bir iletişim aracının çok ötesine geçmiş durumda. Kişisel veriler, finansal bilgiler, kurumsal yazışmalar ve benzersiz kullanıcı kimlikleri bu cihazlarda barındırılıyor. Bu gerçek, cihaz üreticilerini katmanlı güvenlik mekanizmaları geliştirmeye zorlamakta; teknik servis uzmanlarını ise zaman zaman kendi müşterilerinin verilerine bile erişemeyen bir konuma düşürmektedir.

Bunun tam ortasında, çoğu teknisyenin adını pek de duymadığı ama olası her profesyonel veri kurtarma senaryosunda karşılaşabileceği bir bileşen yer almaktadır: Replay Protected Memory Block — kısaca RPMB.

Peki ne zaman gerçekten bu soruna takılırsınız? Senaryo şu şekilde gelişebilir: Parola kırma denemeleri sırasında cihazın veri silme rutinini yanlışlıkla tetiklersiniz. Flash belleğin tam bir yedeğini alıp geri yüklersiniz, ne var ki cihaz yine de açılmaz. İşte tam bu noktada, sorunun aslında flash verisiyle değil, eMMC içindeki küçük ama son derece kritik RPMB bölümüyle ilgili olduğunu fark edersiniz.

“Sistemin güvenliği, yalnızca en zayıf halkası kadar güçlüdür. RPMB kimlik doğrulaması ne kadar sağlam görünse de donanım katmanındaki açıklar, tüm güvenlik katmanlarını işlevsiz kılabilir.”

RPMB Nedir? Kimlik Doğrulama Mekanizması Nasıl Çalışır?

Replay Protected Memory Block (RPMB), JEDEC standartları kapsamında modern depolama aygıtlarına — başta eMMC (embedded Multi Media Card) ve UFS (Universal Flash Storage) — entegre edilmiş, kimlik doğrulamalı ve tekrar saldırılarına karşı korumalı özel bir bellek bölümüdür.

RPMB Yazma İşlemi Nasıl Gerçekleşir?

RPMB bölümüne her yazma işlemi, katı bir protokol zincirine tabidir. Bu zincirin kırılması, yazmanın reddedilmesine yol açar:

1. 1
   Paylaşımlı Anahtar (Pre-shared Key): Akıllı telefon fabrikadan çıkmadan önce eMMC çipine ve ana işlemciye özgü bir kimlik doğrulama anahtarı programlanır. Bu anahtar, cihazın ömrü boyunca değiştirilemez niteliktedir.
2. 2
   HMAC-SHA256 Hesaplama: Ana işlemci (host), yazmak istediği veriyi ve mevcut yazma sayacı değerini bu anahtarla şifreleyerek bir HMAC mesaj doğrulama kodu üretir.
3. 3
   Sayaç Doğrulama: eMMC çipi gelen mesajı alır, kendi sakladığı anahtar ile HMAC’yi yeniden hesaplar ve iletilen sayacın kendi dahili sayacıyla eşleşip eşleşmediğini kontrol eder.
4. 4
   Yazma İzni: Yalnızca her iki doğrulama da başarıyla tamamlandığında yazma işlemine onay verilir. Herhangi bir uyumsuzluk, işlemi kesinlikle reddeder.

  ┌─────────────────────────────────────────────────────────────────────┐
  │                     RPMB YAZMA PROTOKOLÜ                            │
  ├────────────────────────┬────────────────────────────────────────────┤
  │   ANA İŞLEMCİ (HOST)   │             eMMC ÇİPİ                      │
  ├────────────────────────┼────────────────────────────────────────────┤
  │ 1. Veri hazırla        │                                            │
  │ 2. Sayaç değerini oku  │◄──── Sayaç okuma isteği ──────────         │
  │ 3. HMAC hesapla │                                                   │
  │    (veri + sayaç +key) │                                            │
  │ 4. Mesajı gönder ──────┼──►  5. HMAC doğrula (kendi anahtarıyla)    │
  │                        │     6. Sayaç eşleşiyor mu?                 │
  │                        │     7. ✓ Evet → Yaz, sayacı artır          │
  │                        │        ✗ Hayır →Reddet, hata döndür        │
  └────────────────────────┴────────────────────────────────────────────┘

RPMB Akıllı Telefonlarda Nerelerde Kullanılır?

Hedef Cihaz: Blackphone 2 ve Araştırma Arka Planı

Araştırmanın çıkış noktası, kendi başına ilgi çekici bir hikâyeye sahip.adli tıp analiz laboratuvarında çalışan araştırmacılar, Blackphone 2 üzerinde kaba kuvvet parola kırma yöntemi geliştirirken yanlışlıkla cihazın veri silme rutinini tetikler. Flash belleğin yedeğini geri yüklediklerinde cihazın yine de açılmadığını fark edince yoğun bir ters mühendislik sürecine girerler.

Güvenilir Yürütme Ortamı: Qualcomm QSEE’nin Anatomisi

Bir akıllı telefonun içinde aslında iki ayrı işlemci “dünyası” koşturmaktadır. Bu kavramı anlamadan RPMB güvenlik açığını kavramak mümkün değildir. Qualcomm TrustZone teknolojisi, aynı fiziksel işlemci üzerinde birbirinden kesin çizgilerle ayrılmış iki ortam oluşturur:

  ┌──────────────────────────────────────────────────────────────────────┐
  │                   TrustZone ARM Mimarisi                             │
  ├───────────────────────────┬──────────────────────────────────────────┤
  │  REE (Normal Dünya)       │  TEE (Güvenli Dünya)                     │
  │  Rich Execution Env.      │  Trusted Execution Env.                  │
  ├───────────────────────────┼──────────────────────────────────────────┤
  │  EL0: Kullanıcı alanı     │  EL0: Güvenilir Uygulamalar (TA)         │
  │  EL1: Linux Çekirdeği     │  EL1: QSEE Çekirdeği                     │
  │  EL2: Hypervisor          │                                          │
  │                           │                                          │
  ├───────────────────────────┴──────────────────────────────────────────┤
  │            EL3: Secure Channel Monitor (En Yüksek Ayrıcalık)         │
  │        ← SMC (Secure Monitor Call) aracılığıyla mesajlaşma →         │
  ├──────────────────────────────────────────────────────────────────────┤
  │  TZASC: TrustZone Address Space Controller (Veri Yolunda Ayırıcı)    │
  └──────────────────────────────────────────────────────────────────────┘

QSEE: Qualcomm’un Kapalı Kaynak Güvenli İşlem Ortamı

QSEE (Qualcomm Secure Execution Environment), kaynak kodu kamuya açık olmayan, yüksek ayrıcalıklı güvenli işletim sistemidir. Parola kontrolü, şifre çözme anahtarı türetme ve RPMB okuma/yazma işlemlerinin tamamı bu ortamda gerçekleşir. Normal Android işletim sistemi, QSEE’ye yalnızca özel bir çekirdek aygıtı (/dev/qseecom) üzerinden SMC çağrıları aracılığıyla ulaşabilir.

vold: Android Hacim Daemon’ı ve Şifre Doğrulama Akışı

Kullanıcı parolasını girdiğinde sahne arkasında şu süreç işler: Android’in vold (Volume Daemon) süreci, libQSEEComAPI.so paylaşım kütüphanesi aracılığıyla QSEE’ye QSEECOM_IOCTL_CREATE_KEY_REQ isteği gönderir. QSEE bu isteği değerlendirerek üç olası sonuçtan birini döndürür:

Anahtar Türetme ve RPMB’nin Şifreleme Sürecindeki Rolü

İşte konunun teknik servis açısından en kritik noktasına geliyoruz. QSEE, FDE (Tam Disk Şifreleme) anahtarını ve hatalı parola sayacını keystore adı verilen şifreli bir veri yapısında tutar. Bu yapı, flash bellekteki ssd bölümünde saklanır. Peki RPMB bu noktada devreye nasıl giriyor?

Keystore Kimlik Doğrulama Zinciri

Keystore’un HMAC’si yalnızca şifreli veri üzerinden değil, aynı zamanda RPMB bölümündeki anti-rollback sayacını da kapsayacak şekilde hesaplanır. Bu tasarımın anlamı şudur: Saldırgan eski bir keystore yedeklemesini geri yüklediğinde, RPMB’deki sayaç değeri artık bu yedeğin üretildiği andaki değerle örtüşmeyecektir. Sonuç olarak HMAC doğrulaması başarısız olacak ve FDE anahtarı bir daha hiç yüklenemeyecektir.

  ┌──────────────────────────────────────────────────────────────────┐
  │              KEYSTORE KİMLİK DOĞRULAMA AKIŞI                     │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │  QSEE Başlatılır                                                 │
  │       │                                                          │
  │       ▼                                                          │
  │  RPMB'den anti-rollback sayacı okunur ──────────────────────┐    │
  │       │                                                     │    │
  │       ▼                                                     │    │
  │  flash'tan keystore şifreli verisi okunur                   │    │
  │      │                                                      │    │
  │      ▼                                                      │    │
  │  HMAC = SHA256(şifreli_veri + RPMB_sayacı + HBK)   ◄────────┘    │
  │      │                                                           │
  │      ├──► HMAC eşleşiyor? →Keystore çözülür →FDE anahtarı yüklenir
  │      │                                                           │
  │      └──► HMAC eşleşmiyor? → KRİTİK HATA → Şifre çözme imkânsız  │
  │                                                                  │
  │           30 yanlış deneme sonrası:                              │
  │  • FDE anahtarı keystore'dan silinir                             │
  │  • Keystore yeniden şifrelenerek flash'a yazılır                 │
  │  • RPMB anti-rollback sayacı 1 artırılır                         │
  └──────────────────────────────────────────────────────────────────┘

eFuse Denetimi ve Tek Seferlik Programlama

QSEE her başlatıldığında eMMC’nin RPMB kimlik doğrulama anahtarının programlı olup olmadığını denetler. Eğer programlanmamışsa, önce bir eFuse değerini sorgular. eFuse, anahtarın daha önce hiç programlanıp programlanmadığını gösterir. Yalnızca hiç programlanmamış bir eMMC’ye anahtar yazılabilir. Bu mekanizma, saldırganın boş bir eMMC takarak anahtar programlama sürecini izlemesini engellemek amacıyla tasarlanmıştır.

eMMC Donanım Analizi: Çip İçini Okumak

Araştırmacılar, yazılım katmanında RPMB’nin nasıl kullanıldığını anladıktan sonra asıl soruyu sordular: Kimlik doğrulama anahtarı fiziksel olarak nerede tutulur?

Hynix eMCP Çipinin Mimarisi

Blackphone 2, eMMC ve DRAM’ı tek bir paket içinde barındıran Hynix H9TQ26ADFTMCUR eMCP çipini kullanmaktadır. Bu çip mimarisinde dikkat çeken bir ayrım vardır: Flash bellek kontrolörü ve DRAM, standart arayüz pinlerine bağlıyken, ham NAND flash bellek dieleri bu pinlere değil, teknik pinlere (technical pins) bağlanmıştır.

Anahtar Programlama Sırasında İletişim İzleme

Araştırmacılar, teknik pinlere bir mantık analizörü bağlayarak, mmc-util paketi ile test eMMC’sine anahtar programlanırken kontrolör ile NAND dieleri arasındaki iletişimi kaydettiler. Elde ettikleri bulgular son derece aydınlatıcıydı:

RPMB Kimlik Doğrulama Anahtarının Ham Bellekten Çıkartılması

Teorik güvenlik ile pratik güvenlik arasındaki uçurumu gösteren en çarpıcı bulgulardan biriyle karşılaşıyoruz. JEDEC standardı, RPMB kimlik doğrulama anahtarının okunaksız ve değiştirilemez bir “tek seferlik programlanabilir” kayıtta tutulmasını şart koşar. Gerçeklik ise çok daha farklıdır.

Düz Metin Anahtar Depolama: Kritik Güvenlik Açığı

Araştırmacılar, teknik pinlere bir flash bellek okuyucu bağlayarak ham NAND verisi aldılar. Elde edilen ham veri, XOR tabanlı bir karıştırma (scrambling) deseniyle şifreli geldi. Scrambling desenini çözümlemek için, tüm baytları 0x00 olan boş bir referans eMMC kullanıldı. Desen kaldırıldığında ortaya çıkan sonuç şaşkınlık verici oldu:

// Referans eMCP üzerinden elde edilen düz metin veri örüntüsü
// (Gerçek adres: 0x0E00 offset bölgesi)
... 00 00 00 00 00 00 00 ...
[PASS] 31 32 33 34 35 36 37 38  // "12345678" ASCII
       39 30 31 32 33 34 35 36  // "90123456"
       37 38 39 41 42 43 00 00  // "789ABC" + dolgu
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// Kimlik doğrulama anahtarı [PASS] bayrağından
// hemen sonra DÜZMETN olarak saklanmaktadır!
// Herhangi bir şifreleme veya gizleme YOKTUR.

Diğer Üreticilerde Benzer Bulgular

Araştırmacılar, aynı tekniği farklı üreticilerin eMMC çiplerine uyguladıklarında benzer zafiyetleri tespit ettiler. Her model farklı bir adres kullanmaktadır, bu nedenle ilgili adresin belirlenmesi için anahtar programlama sürecinin sniffing ile izlenmesi gerekmektedir:

Silinmiş Durumdaki Akıllı Telefondan Veri Kurtarma: Adım Adım

Araştırmacılar, tüm bu teorik bulguları somut bir kurtarma deneyi ile sınadılar. Blackphone 2 üzerinde kasıtlı olarak veri silme rutini tetiklendi ve ardından cihaz kademeli olarak çalışır duruma geri getirildi.

Donanım Hazırlık Aşaması

1. 1
   eMCP Söküm: Sıcak hava tabancasıyla eMCP çipi PCB’den kaldırıldı. SD adaptör üzerinden Linux bilgisayara bağlandı. Tüm bölümler (mmcblk0, mmcblk0boot0/1, mmcblk0rpmb) NIST yönergelerine uygun şekilde görüntülendi (baseline).
2. 2
   RPMB Anahtarı Çıkartma: Teknik pinler flash bellek okuyucuya bağlandı. RPMB kimlik doğrulama anahtarı, referans eMCP ile aynı adresten başarıyla elde edildi.
3. 3
   ISP Pin Kurulumu: eMCP PCB’ye yeniden lehimlendi. Aynı anda CLK, CMD ve D0 eMMC hatları ince tellerle ISP (In System Programming) pinlerine uzatıldı. Bu sayede çipi sökmeden RPMB bölümüne doğrudan okuma/yazma yapılabilir hale geldi.

Veri Silme Rutininin Tetiklenmesi

Yazılım tarafında bootloader kilidinin açılabilmesi için, devinfo bölümündeki 0x10 ve 0x18 offset değerleri 0x01 olarak değiştirildi. Qualcomm EDL (Emergency Download Mode) üzerinden sızdırılan bir programlayıcı kullanıldı. Magisk ile özel bir boot imajı oluşturularak ADB root kabuğu elde edildi.

# ADB root kabuğunda çalıştırılan parola deneme komutu
vdc cryptfs checkpw <parola>
# 30 yanlış denemeden sonra QSEE tarafından dönen değer:
# 0xFFFFFFF6 (-10) → Veri silme rutini tetiklendi
# Cihaz yeniden başlar ve tüm kullanıcı verisi silinir

Veri Silme Sonrası RPMB Değişimi

Veri silme öncesi ve sonrası RPMB bölümünün karşılaştırılması, son derece kritik bir bulguyu ortaya koydu:

Başarısız Kurtarma Denemesi: Flash Yedekten Geri Yükleme

Araştırmacılar önce yalnızca 29 GB boyutundaki ana eMMC bölümünü yedeğinden geri yüklediler. Cihaz boot ekranına kadar geldi, doğru parola girildi, ancak işletim sistemi kullanıcıya şifre çözme başarısızlığını bildirdi. Bu beklenmedik bir sonuç değildi — aksine ters mühendislik bulgularının mükemmel bir doğrulamasıydı:

Başarılı Kurtarma: RPMB Verisini de Geri Yüklemek

1. 1
   Tam eMMC Geri Yükleme: Ana eMMC bölümünün tamamı (29 GB) tekrar baseline yedeğinden geri yüklendi.
2. 2
   RPMB Verisi Yazma: ISP pinleri üzerinden, daha önce çıkartılan RPMB kimlik doğrulama anahtarı kullanılarak RPMB bölümü de orijinal haline (0x20C = 0x10) geri yazıldı.
3. 3
   Sonuç: Cihaz başarıyla açıldı. Doğru parola ile kullanıcı verilerine eksiksiz biçimde ulaşıldı. Yazma sayacı artışına rağmen QSEE müdahaleyi hiç tespit etmedi.

Tespit Edilen Güvenlik Zafiyetlerinin Sistematik Analizi

Araştırma sürecinde üç temel güvenlik açığı net biçimde ortaya konulmuştur. Bunları katmanlı bir şekilde değerlendirmek, benzer cihazları inceleyen teknik servis uzmanları için kritik bir çerçeve oluşturmaktadır.

JEDEC Standardı ile Gerçek Uygulama Karşılaştırması

Güvenlik Açıklarını Kapatmaya Yönelik Öneriler ve Olası Çözümler

Araştırma ekibi bulgularını Haziran–Temmuz 2023’te Silent Circle ve SK Hynix’e sorumlu açıklama (responsible disclosure) ilkeleri çerçevesinde bildirmiştir. Belgelenen açıkların kapatılması için üç katmanlı bir yaklaşım önerilmektedir: