Hash, imza, yeniden üretilebilir derleme ve denetim farklı soruları yanıtlar.
Açık kaynaklı olmak, kodun incelenmesini sağlar; ancak tek başına kurulu uygulamanın aynı kod olduğunu veya hiçbir güvenlik açığı bulunmadığını kanıtlamaz. Bir mesajlaşma uygulamasını değerlendirirken farklı kanıt türlerini ayırmak daha iyidir: kaynak kodu, derleme süreci, dosya imzası, protokol testi ve denetim raporu.
Her kanıt tam olarak neyi gösterir?
| Kanıt | Başlıca katkısı | Tek başına kanıtlamadığı şey |
|---|---|---|
| Okunabilir kaynak kodu | Tasarım ve uygulamanın incelenebilmesi | Kurulum dosyasıyla eşleşme veya tüm hataların yokluğu |
| Yeniden üretilebilir derleme | Belirli kaynak ve ortamdan çıkan çıktının karşılaştırılabilmesi | Kodun kendisinin güvenli olması |
| APK imzası | İmzanın ve dosyanın güvenilen imzalayan anahtarıyla ilişkisinin kontrolü | Uygulamanın davranışının zararsız olması |
| SHA-256 özeti | Güvenilen bir özete göre bayt farklılıklarının tespiti | Saldırgan dosyayı ve özeti birlikte değiştirdiğinde özgünlük |
| Test vektörü | Belirli giriş ve çıkış için belirli davranışın kontrolü | Tüm durumların ve yürütme yollarının kapsanması |
| Bağımsız denetim | Belirli bir kapsam ve sürüm incelemesinin bulguları | Gelecekteki bütün sürümlerin kalıcı garantisi |
Yeniden üretilebilir derleme, aynı özete sahip dosyayı indirmek değildir
Reproducible Builds tanımına göre yeniden üretilebilirlik, belirli kaynak, ortam ve talimatlardan aynı çıktının oluşturulmasıyla ilgilidir. Yalnızca indirdiğiniz dosyayı geliştiricinin yayımladığı özetle karşılaştırırsanız bir bütünlük testi yapmış olursunuz; dosyayı henüz kendiniz koddan derlememişsinizdir.
Yeniden üretilebilirlik iddiasını değerlendirmek için kod sürümünü, bağımlılıkları, derleme talimatlarını ve sonucu tekrarlayan başka birinin raporunu isteyin. “Kaynak GitHub’da mevcut” ifadesi bu kanıtların yerini tutmaz.
APK incelemesini nasıl doğru yorumlarız?
- Dosyayı resmî kanaldan ve belirli bir sürüm olarak edinin.
- Özeti ve imzalayan bilgilerini özgünlüğüne güvendiğiniz bir kaynaktan alın.
- Dosyanın özetini hesaplayın ve aynı sürümle karşılaştırın.
- Teknik incelemede imzayı da doğrulayın; resmî apksigner aracı bunu destekler.
- Fark görürseniz kurulumu durdurun ve nedenini açıklığa kavuşturun; hatayı aşmak için dosyayı yeniden imzalamayın.
Android SDK Build Tools sahibi bir uzman için örnek doğrulama komutu:
apksigner verify --verbose --print-certs app.apk
app.apk adı yalnızca örnektir. Komutun başarılı olması, yayıncının geçerli anahtarını tanıma gereğini ortadan kaldırmaz.
Proof Lab’ın rolü nedir?
Livara Proof Lab, belirli kontroller için araçlar sunar. Her testin kapsamını okuyun: dosya özeti, anahtar anlaşması örneği veya değiştirilmiş verinin reddedilmesi farklı sorulardır. Bir kriptografi gösteriminin başarılı olması; kurulu uygulamanın tamamının, sunucunun, güncellemelerin veya hesap yönetiminin denetimi değildir.
Livara tehdit modeli de saldırgan hem APK dosyasını hem gösterilen özeti değiştirirse, yalnızca özet eşleşmesinin özgünlüğü kanıtlamadığını belirtir. Bu, belirli bir mesajlaşma uygulamasının özelliği değil, özet kontrolünün genel bir sınırıdır.
Denetim raporunu okurken ne sormalıyız?
- İncelemeyi hangi kuruluş veya kişiler yaptı ve kamuya açık rapor nerede?
- Hangi sürüm ve commit incelendi?
- Hangi bölümler kapsam dışında kaldı?
- Önemli bulgular nasıl giderildi ve yeniden test edildi?
- Kurulu sürümünüz aynı sürüm mü veya onun düzeltmelerini içeriyor mu?
Bu sorular yanıtlanmadan “onaylanmış” gibi sözcüklerden kesin sonuç çıkarmayın. Standart bir algoritma kullanılması da ürünün tamamının standart sertifikasına sahip olmasıyla eşdeğer değildir.
Mesajlaşma uygulaması seçimi için sonuç
Açık kaynaklılık ve doğrulanabilirlik birbirinin rakibi değildir; tamamlayıcı kanıtlardır. İddiaları kesin, izlenebilir ve kapsamı açık ürünleri tercih edin. Ardından aynı incelemeyi grup, web sürümü, yedekleme ve bağlı cihazlar gibi kullandığınız moda uygulayın; tek bir başarılı testten mutlak güvenlik sonucuna varmayın.
