Mesaj bütünlüğü: Sunucu şifreli sohbeti değiştirebilir mi?

Bir mesajlaşma uygulaması düzenleme veya silme özelliği sunabilir; ancak kimlik doğrulamalı şifreleme kullanan bir sistemde sunucu, şifreli metni sessizce değiştirip yine de geçerli bir mesaj teslim edememelidir. Mesajlaşma uygulamasında mesaj bütünlüğü, alıcının verinin şifrelemeden sonra değiştirildiğini anlayabilmesidir; bu, tam geçmişi saklamak veya konuşmayı hukuken kanıtlamakla aynı şey değildir.

Temel noktalar

• Kimlik doğrulamalı şifreleme, şifreli metnin kurcalandığını ortaya çıkarır; ancak düzenleme ve silme geçmişini mutlaka tutmaz.
• Livara’nın teknik belgelerine göre AES-256-GCM özel mesajları bir doğrulama etiketiyle korur; değiştirilmiş bir paket geçerli biçimde çözülememelidir.
• Yetkili düzenleme, sunucunun önceki paketi gizlice yeniden yazması değil, yeni ve uçtan uca şifrelenmiş bir olay olmalıdır.
• Güvenlik numaraları karşı tarafın anahtarını kontrol etmeye yardımcı olur; dürüstlüğünü veya ekran görüntüsünün hukuki geçerliliğini ölçmez.
• Hassas uyuşmazlıklarda özgün dosyayı, zamanları, düzenleme durumunu ve bağımsız kanıtları sohbet dizisinin dışında da saklayın.

Mesajlaşma uygulamasında mesaj bütünlüğü tam olarak nedir?

Mesaj bütünlüğü, alıcının şifreli verideki yetkisiz değişikliği saptayabilmesidir. Gizlilik “Metni kim okuyabilir?” diye sorar; bütünlük ise “Gönderenin şifrelediği veriyle aynı veri mi ulaştı?” diye sorar. Uçtan uca şifreleme ve sınırlarının açıklaması bu farkı daha ayrıntılı anlatır.

Görsel, gösterim amaçlı etiketler içeren kavramsal bir illüstrasyondur; gerçek Livara arayüzü veya değiştirilmiş bir mesajın reddedilmesine ilişkin test sonucu değildir.

Livara’nın teknik belgelerine göre doğrudan mesajlar LVR1, uyumlu özel gruplar ise LGS1 ile uçtan uca şifrelenir. Livara güvenlik sayfasına göre uyumsuz eski gruplar açıkça E2EE dışında kalır ve tüm üyeler hazır olmadan yeni bir grup şifreli etiketiyle oluşturulmaz. İlgili sohbetin durumunu kontrol edin. Bu belgeler, LVR1’in mesaj anahtarı türetmek için ECDH P-256 ve ML-KEM-768 kullandığını belirtir. Bir bileşenin standart olması, tüm birleşimin veya ürünün bağımsız olarak onaylandığı anlamına gelmez. Livara daha sonra içeriği korumak için AES-256-GCM kullanır.

Ürün belgelerine göre bu koruma, özel sohbetlerin metnini, düzenlemelerini ve eklerini kapsar. Ancak Livara kanalları uçtan uca şifreli değildir: Sunucu, kötüye kullanım içeriğini kaldırmak da dahil amaçlarla içeriklerini bilinçli olarak okuyabilir. Grup üyeliği de sunucunun kontrolündedir. Aramaların güvenliği ve kayıt modu da metin mesajlarından ayrı incelenmelidir.

Şifreli mesajda değişikliği saptamak ve mesajlaşmada AES-256-GCM şifrelemesi

AES-GCM, içeriği şifrelemenin yanında doğrulama etiketi üretir. Şifreli metin veya kimliği doğrulanan veri değişirse etiket kontrolü başarısız olmalıdır. NIST SP 800-38D, GCM modunu tanımlar ve aynı anahtarla nonce tekrarının güvenliği ciddi biçimde zayıflatabileceği konusunda uyarır.

Livara’nın teknik özelliklerine göre özel mesajlar AES-256-GCM kullanır. Sunucu korunan paketin bir bölümünü değiştirirse mesaj anahtarı olmadan yeni bir doğrulama etiketi oluşturamaz; dolayısıyla alıcı paketi sağlam kabul etmemelidir. “Sunucu mesajı değiştirebilir mi?” sorusunun kısa yanıtı şudur: Sunucu veriyi silebilir, tutabilir, engelleyebilir veya geciktirebilir; ancak değiştirilmiş içeriği geçerli gösterememelidir.

Bu garanti sınırsız değildir. Kriptografi cihazdaki kötü amaçlı yazılımı, saldırganın açık ekrana erişimini veya kullanıcının yetkili düzenlemesini etkisizleştiremez. İçerik bütünlüğü metadatayı da mutlaka gizlemez. Mesajlaşma metadatası ve ortaya çıkardıkları rehberi bu sınırı açıklar.

Sunucu mesajı değiştirebilir mi, yoksa düzenleme başka bir şey mi?

Sunucu önceki şifreli paketi gizlice yeniden yazamamalıdır; ancak gönderenin oluşturduğu bir düzenleme olayını teslim edebilir. Mesaj düzenleme güvenliği, sunucunun kayıtlı metni doğrudan değiştirmesine değil, düzenlemenin de özgün mesaj gibi doğrulanıp uçtan uca şifrelenmesine bağlıdır.

Livara belgelerine göre doğrudan sohbette düzenleme LVR1, uyumlu özel grupta ise LGS1 altında korunur. Arayüzü değerlendirirken uygulamanın “düzenlendi” durumunu gösterip göstermediğini kontrol edin; yine de kriptografi tek başına önceki sürümü tüm cihazlarda sonsuza dek saklamaz.

“Herkesten sil” de içeriği kaldırma isteğidir; tüm kopyaların yok edildiğinin kanıtı değildir. Alıcı mesajı görmüş, bildirimi okumuş, dosyayı kaydetmiş veya ekran görüntüsü almış olabilir. Kaybolan mesaj, kalıcılığı azaltır; ancak tüm kopyaların silindiğini garanti etmez.

Sohbet mesajının doğrulanması neyi kanıtlar?

Sohbet mesajının doğrulanması, mesajın oturum anahtarlarıyla oluşturulduğunu ve yolda değiştirilmediğini gösterir. Hesap sahibinin cihazı bizzat elinde tuttuğunu, metnin doğru olduğunu veya alıcının bunu daha sonra üçüncü kişiye kesin biçimde kanıtlayabileceğini göstermez.

Livara teknik belgelerinde güvenlik numaralarını anahtar değişimini saptama yolu olarak sunar. İki kişi anahtar parmak izlerini bağımsız bir kanal üzerinden karşılaştırabilir; güvenlik numaralarıyla sohbet kontrolü rehberi uygulama adımlarını açıklar. Bu kontrol, kişinin anahtarının saldırganın anahtarıyla değiştirilmesi riskini azaltır; ancak enfekte cihazı güvenli yapmaz.

Hesap kimlik doğrulaması da ayrı bir konudur. Hiçbir giriş mekanizması, ne kadar güçlü olursa olsun mesaj bütünlüğünün, kişinin anahtarını doğrulamanın veya cihaz güvenliğinin yerini tutmaz.

İçerik bütünlüğü, mesaj sırası ve güncelliğiyle aynı değildir

Eski bir paketin geçerli doğrulama etiketi olabilir. Tekrar kabul edilmesini önlemek protokol tasarımı, sayaçlar, oturum kimliği ve alıcının durum tutmasını gerektirir; AES-GCM tek başına tüm konuşmanın sıra kayıt defteri değildir. Bu fark yeniden oynatmayı, geciken mesajları ve çok cihazlı eşitlemeyi değerlendirirken önemlidir.

Ayrıca hangi verinin gerçekten doğrulama etiketi kapsamına girdiği belirlenmelidir. Sohbet kimliği veya olay türü doğrulanmış bağlamın dışındaysa yalnızca gövdeyi korumak sorunun tamamını çözmez. Kod incelemesi ve aynı sürümün testi bu ilişkiyi açıklığa kavuşturmalıdır.

Mesaj metni veya durumu beklenmedikse

Uygulama sürümünü, gözlem zamanını, ilgili cihazları ve düzenleme etiketinin varlığını kaydedin. Kişiyle bağımsız bir kanal üzerinden yetkili düzenleme yapıp yapmadığını kontrol edin. Eşitleme farkını kanıt olmadan sunucunun kurcalamasına bağlamayın; ancak doğrulama hatasını veya anahtar değişimini de gerekçesiz görmezden gelmeyin.

Teknik rapor için hassas olmayan bir test mesajı kullanın ve kişinin özel verilerini herkese açık rapora koymayın. Konuşma hukuki bir konuda kullanılacaksa kriptografi veya ekran görüntüsü tek başına hukuki geçerliliği belirlemez; kanıtı değiştirmeden önce yetkin bir uzmandan yardım alın.

Bir mesajlaşma uygulamasının bütünlük iddiasını nasıl değerlendiririz?

“Şifreli” ifadesiyle yetinmeyin. Şunları sorun:

• Hangi sohbetler ve dosyalar uçtan uca şifrelenir?
• Hizmet hangi AEAD algoritmasını kullanır?
• Düzenleme ve silme nasıl kaydedilir ve gösterilir?
• Kullanıcı kişinin anahtarındaki değişikliği nasıl saptar?
• Sunucu hangi metadata, içerik veya üyeliği kontrol eder?
• Aramalar mesajlarla aynı garantilere sahip mi?
• Protokol bağımsız olarak denetlendi mi?

Livara bazı iddialarını incelemek için özellikler ve araçlar yayımlar; Android kullanıcıları APK dosyasının sağlama toplamını uygulamayı çevrimdışı kontrol etmek için Proof Lab’da SHA-256 ile karşılaştırabilir. Ancak bu makale mevcut sürümün bağımsız denetimine ilişkin kanıt sunmaz. Özelliklerin ve test vektörlerinin yayımlanması incelemeye yardımcı olur, fakat bağımsız denetimin yerini tutmaz.

Özel sohbetler için Livara’nın temel iddiası sınırlı ve açıktır: AES-256-GCM paketin değiştirilmesini ortaya çıkarmalı ve düzenlemeler de şifrelenmelidir. Bu iddia, değişmez bir kayıt defteri, tüm kopyaların kesin silinmesi veya otomatik hukuki kanıt anlamına gelmez.

Sık sorulan sorular

Sunucu yöneticisi şifreli mesaj metnini değiştirebilir mi?

AES-256-GCM ile doğru tasarımda sunucu yöneticisi mesaj anahtarı olmadan şifreli metni değiştirip geçerli doğrulama etiketi oluşturamaz. Yine de paketi silebilir, engelleyebilir veya geciktirebilir. Bu garanti, enfekte cihazı veya gönderenin yetkili düzenlemesini kapsamaz.

“Düzenlendi” etiketi önceki sürümün ne olduğunu kanıtlar mı?

Hayır. Uygulama sürüm geçmişini de tutmuyorsa bu etiket yalnızca görüntülenen içeriğin gönderildikten sonra değiştiğini söyler. Şifreleme düzenleme olayının doğruluğunu denetleyebilir, ancak önceki metni kendiliğinden saklamaz.

Güvenlik numarası tüm mesajların doğruluğunu garanti eder mi?

Hayır. Güvenlik numarası şifreleme anahtarının kişiye ait olduğunu kontrol etmeye ve değişimini saptamaya yardımcı olur. Gönderim sırasında cihazı kimin tuttuğunu, mesajın doğru olduğunu veya cihazda kötü amaçlı yazılım bulunmadığını söylemez.

Herkesten silme mesajı her yerden kaldırır mı?

Hayır. Bu özellik uygulama içindeki kopyayı kaldırabilir; ancak kaydedilmiş dosyayı, bildirimi, ekran görüntüsünü veya önceki kaydı geri alamaz. Herkesten silme kalıcılığı azaltır; alıcının cihazından veya başka sistemlerden silinmeyi garanti etmez.