Disk kopyası, çalışan sunucunun kontrolü ve telefona erişim üç ayrı senaryodur; tek bir genel garanti üçünü birden karşılamaz.
Bir mesajlaşma sunucusu ele geçirilirse “ne açığa çıkar?” sorusunun kesin yanıtı, saklanan verilere, anahtarların konumuna ve saldırganın erişim türüne bağlıdır. Diskin bir kopyasını almak, çalışan hizmeti ve uygulamanın dağıtım yolunu kontrol etmekle aynı şey değildir.
Bu makale, Livara'nın herkese açık belgelerine dayanarak varsayımsal bir senaryoyu inceler. Livara veri merkezlerinin konumu, el koyma olayının gerçekleştiği veya internet kesintisinde hizmetin çalışacağının garantisi hakkında iddiada bulunmaz. İçerik şifreleme, ağın kullanılabilirliği ve altyapı güvenliği ayrı konulardır.
Önce erişim türünü belirleyelim
Saklanan sunucu kopyası: saldırgan, o kopyada bulunan dosyalara, veri tabanına veya yedeklere erişir. Özel içerik cihazda doğru şekilde şifrelenmişse ve sunucu çözme anahtarına sahip değilse, yalnızca bu kopyaya sahip olmak konuşma metnini açığa çıkarmaz.
Hizmetin etkin kontrolü: saldırgan, mevcut verileri okumanın yanı sıra bazı istekleri engelleyebilir, eski verileri döndürebilir veya kontrol ettiği bölümlerin davranışını değiştirebilir. Bu senaryoda karşı tarafın kimliğinin denetlenmesi, sürüm kontrolü ve istemcinin bütünlüğü daha önemli hâle gelir.
Cihaza eş zamanlı erişim: kilidi açık bir telefon, kötü amaçlı yazılım veya konuşma üyelerinden birindeki okunabilir kopya, içeriği tamamen farklı bir yoldan açığa çıkarabilir. Livara tehdit modeli de kilidi açık veya enfekte bir cihazın korunmasını garanti etmez.
Livara belgelerine göre sunucuda hangi veriler görülebilir?
0.1.68 sürüm etiketli Livara güvenlik sayfası, LVR1 kapsamındaki doğrudan sohbetlerin ve LGS1 kapsamındaki uyumlu özel grupların içeriğini operasyonel bilgilerden ayırır. Aynı sayfa, eski ve uyumsuz grupların açıkça E2EE dışında kaldığını belirtir; bu nedenle ilgili konuşmanın durumu kontrol edilmelidir.
| Veri kategorisi | Belgelenen sınır ve olası sonuç |
|---|---|
| Korumalı konuşmanın metni ve ekleri | Sunucu şifreli kopyayı saklar; okumak için uygun anahtar gerekir |
| İletişim meta verileri | Taraflar, zaman, boyut ve teslim durumu gibi bilgiler hizmetin erişimindedir |
| Grup üyeliği | Sunucunun operasyonel bilgilerinin ve yetkisinin bir parçasıdır |
| Açık kanal | İçerik herkese açıktır ve sunucu tarafından okunabilir |
| v7 kimlik kurtarma paketi | Yüklenmeden önce şifrelenir ve ayrı bir kurtarma sırrı gerektirir |
| İsteğe bağlı sunucu kayıt modu | REC işaretiyle E2EE modundan ayrılır; bunun için uçtan uca gizlilik varsayılmamalıdır |
Belgelerde meta veri korumasına yönelik LSS1 kodundan söz edilir, ancak bu kod normal mesaj gönderimine bağlı değildir. Projede bir protokol adının bulunması, tüm iletişimlerde etkin olduğunun kanıtı değildir.
Bu tablo ürünün iddialarını açıklar; gerçek bir el koyma testinin veya tüm veri tabanı kopyalarının bağımsız denetiminin sonucu değildir.
Meta veriler ne kadar önemli olabilir?
İnsanlar arasındaki iletişimler, zamanlar ve grup üyelikleri hakkında bilgiler, mesaj metni olmadan bile hassas olabilir. Ancak saklama süresi, günlüklerin kapsamı ve elde edilen veri kopyası bilinmeden “tüm iletişim grafiği sonsuza dek açığa çıkar” ifadesi kesin değildir.
Gerçek bir değerlendirmede hangi alanların toplandığı, ne kadar süre tutulduğu ve hangi yedeklerin erişilebilir olduğu sorulmalıdır. İçerik şifreleme tek başına veri saklama politikasını belirlemez. Ayrıca bir mesajlaşma hizmetinin mimarisinden, tüm mesajlaşma hizmetlerinin mutlaka aynı meta verileri sakladığı sonucu çıkarılamaz.
Sunucu kontrolü gelecekteki mesajlar için nasıl bir risk oluşturur?
Bir güvenlik incelemesinde üye listesinin değiştirilmesi, farklı bir kimlik anahtarının sunulması, güncellemelerin engellenmesi ve kötü amaçlı istemcinin dağıtılması ayrı ayrı test edilmelidir. Her birinin etkisi, istemci tarafındaki doğrulamaya, değişikliklerin gösterilmesine ve kimlik doğrulamasına bağlıdır.
Uygulama test edilmeden, ele geçirilen her sunucunun mutlaka gizli bir üye ekleyebileceği söylenemez; aynı şekilde etkin sunucu kontrolünün hiçbir etkisi olmadığı da söylenemez. Hassas konuşmalarda beklenmedik kimlik veya üye değişiklikleri incelenmelidir. Anahtar parmak izini karşı tarafla bağımsız ve güvenilir bir yoldan karşılaştırmak, yalnızca görünen ada güvenmekten daha fazla bilgi sağlar.
Saldırgan cihazda çalışan kodu değiştirirse metni şifrelenmeden önce görebilir. Bu nedenle uygulama dağıtımının ve güncellemelerinin güvenliği bu senaryonun bir parçasıdır; kriptografinin dışında bir konu değildir.
Kuantum sonrası olmak ne ekler?
ML-KEM için NIST FIPS 203 standardı, ortak bir sırrın oluşturulmasına yardımcı olur. Hibrit bir bileşimde doğru kullanımı, anahtar değişimine yönelik gelecekteki bazı saldırıların riskini azaltabilir. Bu özellik cihaz güvenliğinin, meta verilerin sınırlı saklanmasının veya sunucu erişim kontrolünün yerine geçmez.
Proof Lab de yalnızca bazı yerel P-256, HKDF ve AES-GCM işlemlerini gösterir ve tam LVR1/LGS1 bileşimini bu deneyin dışında tutar. Başarılı bir sonuç, ürünün tamamının altyapının ele geçirilmesine karşı dayanıklılığını garanti etmez.
Bir değerlendirmede veya gerçek olayda ne yapmalı?
- Erişim türünü ve doğrulanmış bilgileri kaydedin; kesinti söylentisini kesinleşmiş bir güvenlik olayıyla bir tutmayın.
- Uygulama sürümünü ve ilgili konuşmanın şifreleme durumunu kontrol edin.
- Kimlik değişikliklerini, grup üyelerini ve tanınmayan oturumları resmî yollardan inceleyin.
- Kurtarma sırrını, parolayı veya özel içeriği “güvenlik kontrolü” için tanımadığınız kişilere vermeyin.
- Ciddi risk veya hukuki konularda uygun bir uzmandan yardım alın ve tek bir makaleye dayanarak geri döndürülemez işlemler yapmayın.
Güvenilir bir sonuç, hangi verinin hangi sürümde ve hangi erişime karşı korunduğunu belirtmelidir. “Sunucuya el konulsa bile hiçbir şey olmaz” ifadesi bu yanıtın yerini tutmaz.
