Bir mesajlaşma sunucusunun ele geçirilmesi, mutlaka tüm mesajların okunduğu anlamına gelmez. Sonuç; saklanan verilere, anahtarların bulunduğu yere ve saldırganın erişim düzeyine bağlıdır. Sohbet metni doğru şekilde uçtan uca şifrelenmiş olsa bile hesap bilgileri, zamanlar, grup üyeliği ve teslimat yolları hassas olabilir.
Bir olayı değerlendirirken önce saldırganın ne elde ettiğini sorun: Veritabanının bir kopyasını mı, altyapı anahtarlarını mı, çalışan sunucuyu mu, yoksa yazılım yayımlama sistemini mi? Bu senaryoların sonuçları aynı değildir.
Çalınan veritabanı ile kontrol edilen sunucu farklıdır
Yalnızca veritabanının eski bir kopyasına sahip olan saldırgan, o kopyaya kaydedilmiş verilerle sınırlıdır. Canlı hizmetin kontrolü; yeni veri kaydetme, oturum çalma, yanıtları değiştirme veya kişinin anahtarını değiştirmeye çalışma olanağı sağlayabilir. Yazılım dağıtım zincirine erişim ayrı bir risktir: Uç noktadaki kötü amaçlı kod, metni şifrelenmeden önce veya çözüldükten sonra görebilir.
Bu nedenle “veritabanında mesaj metninin anahtarı yok” iddiası önemlidir, ancak tüm sızma türlerine eksiksiz bir yanıt değildir.
Beş mimari modelin karşılaştırılması
Bunlar beş ürünü sıralayan bir liste değil, öğretici modellerdir. Bir hizmet farklı özelliklerinde birden fazla model kullanabilir.
| Model | Veritabanından erişilebilen veriler | Önemli sınır |
|---|---|---|
| Açık metin mesaj ve parola | İçerik ve kimlik bilgileri doğrudan okunabilir | İki veri türü için de uygun koruma yoktur |
| Hash’lenmiş parola, açık metin mesaj | İçerik okunabilir; parola tahminleri test edilebilir olabilir | Parola saklama yönteminin kalitesi sohbet metnini korumaz |
| Sunucu anahtarıyla şifrelenen içerik | Şifreli metin; okunabilmesi anahtara erişime bağlıdır | Anahtar ile verinin gerçekten ayrılması önemlidir |
| Sağlayıcının erişebildiği yedeği olan E2EE sohbet | Canlı sohbet korunabilir, ancak geçmişin kopyası ayrı bir ifşa yoludur | Yedekleme politikası ve anahtarı incelenmelidir |
| Şifreli kurtarma ve bağımsız anahtar kullanan E2EE sohbet | Şifreli metin ve operasyonel veriler; içerik koruması tasarıma ve anahtarın korunmasına bağlıdır | Cihaz, kurtarma ifadesi ve kişinin kimliğini doğrulama hâlâ önemlidir |
Sunucu diskini şifrelemek, ham bir diskin çalınmasına karşı faydalıdır. Saldırgan çalışan hizmete veya şifre çözme anahtarına da sahipse aynı koruma varsayılmamalıdır. E2EE’de amaç, aracı hizmetin korunan içeriği okumak için gereken anahtara sahip olmamasıdır.
Üst veriler neyi gösterir?
Üst veriler hangi hesapların iletişim kurduğunu, ne zaman etkin olduklarını, hangi gruplara üye olduklarını ve ne kadar veri aktarıldığını gösterebilir. Bunlar mesaj metni değildir; ancak iletişim ağını veya etkinlik örüntülerini anlamak açısından değerlidir.
Livara’nın güvenlik sayfası; yönlendirme, üyelik, zamanlar, şifreli metin boyutu ve teslimat durumu gibi operasyonel verilerin saklanmasını ve işlenmesini açıkça anlatır. Özel içeriğin gizliliği, tam anonimlik veya sunucuda hiçbir veri bulunmaması olarak yorumlanmamalıdır.
SRP, hesap verilerini tahmin riskinden muaf tutmaz
SRP, parolanın kendisini doğrudan göndermeden onu bildiğinizi kanıtlama yöntemidir. Sunucu yine de doğrulayıcı, yani verifier verisi tutar. RFC 5054’ün güvenlik bölümü, verifier çalınmasının parola tahmini için sözlük saldırısını mümkün kılabileceğini açıklar.
Dolayısıyla “parola ağ üzerinden gönderilmiyor” ile “çalınabilecek parolayla ilgili hiçbir veri yok” farklıdır. Benzersiz ve güçlü parola, cihaz koruması ve uygun olay müdahalesi hâlâ gereklidir. SRP ayrıca içerik şifrelemesinin veya giriş oturumunun korunmasının yerini tutmaz.
Livara için hangi sınırlar açıklanmıştır?
Livara’nın güvenlik belgesi doğrudan mesajlar için LVR1’i, korunan gruplar için LGS1’i tanımlar. Grubun koruması gerçek durumuna bağlıdır; uyumsuz eski bir grup E2EE etiketi almamalıdır. Herkese açık kanallar bu gizlilik sınırının dışındadır.
Aynı belge v7 kurtarmayı, yüklenmeden önce korunan şifreli bir kimlik paketi olarak tanımlar. Bu süreç sohbet geçmişini değil, kriptografik kimliği geri getirir. Kurtarma ifadesinin veya anahtarların bulunduğu cihazın açığa çıkması, yalnızca veritabanının çalınmasından farklı bir senaryodur.
Bunlar ürünün yayımlanmış açıklamalarıdır; bu makalenin yaptığı bağımsız bir denetimin sonucu değildir. AES veya ML-KEM adının geçmesi de tek başına anahtar yönetiminin ve uygulamanın doğru gerçekleştirildiğini kanıtlamaz.
Bir olay duyurulduğunda hangi soruları sormalıyız?
- Hangi zaman aralığı ve sistemler etkilenmiştir? Belirsiz “kullanıcı bilgileri” ifadesi yeterli değildir.
- Açık metne, dosyalara, anahtarlara, verifier’a, giriş oturumlarına mı, yoksa yalnızca şifreli metne mi erişilmiştir?
- Saldırganın hizmeti veya kullanıcılara dağıtılan yazılımı değiştirme olanağı var mıydı?
- Resmî kanaldan hangi işlemler gereklidir: oturumları kapatmak, parolayı değiştirmek, güncelleme yapmak veya kişinin kimliğini kontrol etmek mi?
- Kurtarma önerisi yerel geçmişi kaybettirebilir mi? Uygulamayı silmeden önce sınırlamaları okuyun.
“Derhâl hesap doğrulama” için anonim bir mesajdaki bağlantıyı kullanmayın. Duyuruyu resmî adresi bağımsız olarak açarak okuyun. Livara’nın tehdit modeli genel sınırları anlamaya yardımcı olur; gerçek bir olayın kapsamı, o olaya ait kanıtlarla belirlenmelidir.
