Uçtan uca şifreleme, kapsadığı içeriği uç cihazlar arasında korur; cihazları veya kullanıcılarını hatasız hâle getirmez.
Uçtan uca şifreleme (E2EE), kapsadığı mesaj içeriklerini okuyabilmek için gereken imkânların iletim hizmetinde değil, iletişime katılan cihazlarda bulunmasını sağlar. Kimin kiminle konuştuğunu kendiliğinden gizlemez, zararlı yazılım bulaşmış bir telefonu güvenli hâle getirmez ve alıcının mesajı kopyalamasını engellemez.
Bu rehber, bir mesajın göndericiden alıcıya yolculuğunu izler; E2EE ile HTTPS arasındaki farkı ve bir mesajlaşma uygulamasının şifreleme iddiasını değerlendirirken yapılabilecek kontrolleri açıklar.
Uçtan uca şifreleme nedir?
Uçtan uca şifreleme, bilginin göndericinin cihazında şifrelenip yalnızca iletişime katılan yetkili bir alıcı cihazında çözülmesini sağlayan bir koruma yöntemidir.
Doğru tasarlanmış bir E2EE görüşmesinde mesaj, gönderici cihazından okunabilir açık metin olarak çıkmaz. Doğru kriptografik anahtar olmadan kullanılamaması gereken şifreli metin olarak çıkar.
Mesajlaşma hizmeti, korunan içeriği okunabilir biçimde görmeye ihtiyaç duymadan şifreli veriyi iletebilir ve eşitleyebilir. Aynı ilke, kullanılan protokole bağlı olarak bire bir veya grup iletişimine uygulanabilir.
Buradaki “uçlar”, iletişime katılan cihazlardır; mutlaka yalnızca iki telefon değildir. Bir grup veya kişinin hesabına bağladığı dizüstü bilgisayar, iletişime başka yetkili uç cihazlar ekleyebilir.
Uçtan uca şifreleme ile sıradan taşıma şifrelemesi arasındaki temel fark budur.
E2EE nasıl çalışır?
İşin matematiği karmaşık olabilir. Ancak bir mesajın temel yolculuğunu anlamak mümkündür.
1. Her katılımcının kriptografik anahtarları vardır
Güvenli bir mesajlaşma istemcisi, kriptografik anahtar malzemesini kullanıcının cihazında oluşturur veya saklar.
Bazı anahtarlar herkese açık biçimde paylaşılabilir. Özel anahtarlar ise korunmalıdır; çünkü cihazın mesajları çözmek için gereken gizli değerleri oluşturmasına veya kurtarmasına yardımcı olurlar.
2. Cihazlar ortak gizli değerler türetir
Katılımcılar, aynı gizli değerlere ulaşmak için gereken herkese açık bilgileri birbirleriyle paylaşır.
Gizli değerin kendisinin okunabilir veri olarak gönderilmesine gerek olmamalıdır. Her cihaz, gerekli kriptografik işlemleri bağımsız olarak gerçekleştirir.
3. Mesaj cihazda şifrelenir
Gönderici Gönder düğmesine dokunduğunda uygulama, mesajı göndericinin cihazında şifreler.
Okunabilir cümle, sunucuya yüklenmeden veya iletilmeden önce şifreli metne dönüşür.
4. Sunucu şifreli metni iletir
Mesajlaşma altyapısı, şifreli mesajı alıcıya yönlendirir. Eşitlemeyi, teslimatı ve birden fazla yetkili cihazı desteklemek için şifreli metni saklayabilir.
Sunucu hâlâ önemli işletim görevleri üstlenir. E2EE, sunucunun işlediği mesaj içeriğinin biçimini değiştirir.
5. Alıcı cihaz mesajı çözer
Yetkili bir alıcı cihaz, kriptografik malzemesini kullanarak şifreli metni kriptografik olarak doğrular ve şifresini çözer.
Okunabilir mesaj, yetkili uç cihazlarda görünür. Yerel geçmiş, bildirimler, yedekler ve dışa aktarılan dosyalar bundan sonra kendi koruma önlemlerine ihtiyaç duyar.
Uçtan uca şifreleme neyi korur?
E2EE öncelikle bir görüşmenin içeriğini korumak için tasarlanır.
Uygulamaya ve teknik gerçekleştirimine bağlı olarak bu içerik şunları kapsayabilir:
- Bire bir yazılı mesajlar
- Fotoğraflar ve videolar
- Sesli mesajlar
- Belgeler ve dosya ekleri
- Sesli veya görüntülü aramalar
- Mesaj düzenlemeleri ve yanıtlar
Bu içerik istemcide doğru biçimde şifrelendiğinde, ağ trafiğini ele geçiren bir saldırganın asıl mesaj yerine şifreli veri görmesi beklenir.
Bu yaklaşım, hizmet altyapısının erişebildiği okunabilir görüşme içeriğini de azaltır.
Ancak “şifreli” sözcüğü tek başına yeterli değildir. Hangi görüşme türlerinin ve içerik iletim yollarının kapsandığı açıkça belirtilmelidir.
E2EE neleri kendiliğinden korumaz?
Uçtan uca şifreleme güçlü bir araçtır, ancak koruma sınırı sıklıkla yanlış anlaşılır.
Mesaj üstverileri
Bir sistem, mesajları yönlendirmek ve eşitlemek için işletim bilgilerine ihtiyaç duyabilir.
Hizmete bağlı olarak bunlar şunları içerebilir:
- Mesajı hangi hesabın gönderdiği
- Mesajın hangi görüşmeye iletildiği
- Ne zaman gönderildiği
- Teslim ve okunma durumu
- Görüşmeye katılan üyeler
- Şifreli mesajın boyutu
- Cihaz veya oturum bilgileri
Mesajın gövdesi okunamaz durumda olsa bile, mesajla ilgili bazı bilgiler sistem tarafından işlenebilir.
Bu nedenle “mesaj içeriği şifreleniyor” ve “hizmet hiç üstveri toplamıyor” birbirinden ayrı iddialardır.
Ele geçirilmiş bir cihaz
Uçtan uca şifreleme, açık metni zararlı yazılımdan veya uç cihaza yeterli erişim sağlamış başka bir saldırgandan korumaz. Bu erişim için cihazın ekran kilidinin açılmış olması şart değildir. Kilitli ekran tek başına, ele geçirilmiş bir işletim sisteminin mesaj verilerine erişemediğini kanıtlamaz.
Mesajın sonunda yetkili bir cihazda okunabilir hâle gelmesi gerekir. Uygulamanın çözülmüş verilerine, belleğine veya ekranına erişen bir saldırgan bu içeriği elde edebilir. Tam olarak hangi bilgilerin açığa çıkacağı cihaza, yazılıma ve saldırının niteliğine bağlıdır.
Cihaz güvenliği bu yüzden önemini korur:
- İşletim sistemi güncellemelerini yükleyin
- Güçlü bir cihaz parolası kullanın
- Tarayıcı uzantılarını gözden geçirin
- Hesap kurtarma bilgilerini koruyun
- Bilinmeyen uygulamalardan ve indirmelerden kaçının
Alıcının yaptıkları
E2EE, bir katılımcının çözülmüş mesajı kopyalamasını, başkasına iletmesini, fotoğrafını çekmesini veya ekran görüntüsünü almasını engelleyemez.
Şifreleme, uç cihazlar arasındaki iletimi korur. Diğer uçtaki kişinin davranışlarını denetlemez.
Hesap kurtarma hataları
Kurtarma sistemlerinin güvenlik ile kullanılabilirliği dengelemesi gerekir.
Zayıf bir kurtarma süreci, güçlü şifrelemeyi etkisizleştirebilir. Buna karşılık kurtarmaya hiç izin vermeyen bir sistemde, anahtar kaybolduğunda şifreli geçmişe erişim kalıcı olarak yitirilebilir.
Güvenilir bir uygulama kurtarmanın nasıl çalıştığını, hangi bilgilerin yedeklendiğini ve kurtarma için gereken bilgiler kaybolduğunda ne olduğunu açıklamalıdır.
E2EE ve TLS aynı şey değildir
Günümüzde çoğu web sitesi, tarayıcı ile sunucu arasındaki trafiği korumak için HTTPS ve TLS kullanır.
Bu önemli bir korumadır. Aynı ağdaki veya iletim yolunun başka noktalarındaki kişilerin bağlantıyı kolayca okumasını ya da değiştirmesini önlemeye yardımcı olur.
TLS, kendi uçları arasındaki bağlantıyı korur. Sıradan web mesajlaşmasında bu uçlardan biri hizmetin kendisidir. Ayrı bir içerik şifreleme katmanı yoksa hizmet, uygulama verilerini okuyabilir. TLS 1.3 belirtimi, bu bağlantıdaki dinlemeye, değiştirmeye ve mesaj sahteciliğine karşı korumayı açıklar.
Sunucunun içeriği okuyabildiği standart mesajlaşmada:
- Cihazınız ağ bağlantısını şifreler.
- Sunucu, okunabilir mesaj içeriğini alır ve işler.
- Sunucu, alıcıya ayrı bir korumalı bağlantı kurar.
Uçtan uca şifrelemede ise mesajın kendisi, korumalı ağ bağlantısına yerleştirilmeden önce katılımcılar için şifrelenir.
Basit bir karşılaştırma:
| Koruma | Yalnızca TLS kullanan mesajlaşma | Uçtan uca şifreleme |
|---|---|---|
| Ağ üzerinden iletimde veriyi korur | Evet | Evet |
| Ağdan geçmeden önce koruma uygulanır | Evet, ilgili TLS bağlantısı için | Evet, hedeflenen mesajlaşma uçları için |
| İletim hizmeti korunan mesaj içeriğini okuyabilir | Ek içerik şifrelemesi yoksa genellikle evet | Amaçlanan anahtar tasarımı doğru uygulanıyorsa yalnızca şifreli metinden okuyamaz |
| Uç cihaz güvenliği yine de gereklidir | Evet | Evet |
| Üstveriler kendiliğinden gizlenir | Hayır | Hayır |
TLS ve E2EE birbirinin rakibi değildir. Özel bir mesajlaşma sistemi genellikle hem güvenli taşımaya hem de doğru uygulanmış içerik şifrelemesine ihtiyaç duyar.
Bu tanım Livara için ne anlama gelir?
Livara'nın güvenlik belgelerine göre, doğrudan iletişimde P-256 ve ML-KEM-768 içeren hibrit LVR1 anahtar anlaşması kullanılır. Uyumlu özel gruplar, ikili oturumlar üzerinden dağıtılan LGS1 gönderici anahtarlarını kullanır. Herkese açık kanallar sunucu tarafından okunabilir ve uçtan uca şifreli olarak tanımlanmamalıdır.
Buradaki ayrım marka adıyla değil, kullanılan iletişim türüyle ilgilidir. Belgeler, farklı bir güven sınırına sahip ve kullanıcıya görünür bir kayıt modu da dâhil olmak üzere arama şifrelemesini ayrıca açıklar. Her özelliğin aynı korumayı sağladığını varsaymak yerine, mevcut görüşmenin ve aramanın durumunu kontrol edin.
Bunlar ürün belgelerindeki açıklamalardır; bu makale için yapılmış bağımsız bir denetimin sonuçları değildir. İşletim üstverileri ve ele geçirilmiş cihazlar önemli koruma sınırları olmaya devam eder. Kuantum sonrası anahtar anlaşması, belirli bir kriptografik risk sınıfını ele alır. Kimlik avını, güvensiz yedekleri veya kilidi açık bir cihazı zararsız hâle getirmez.
Açık anahtar parmak izleri neden önemlidir?
Şifreli bir görüşmede, sistemin sunduğu herhangi bir anahtarla değil, amaçlanan anahtarla iletişim kurmak gerekir.
Açık anahtar parmak izi, bir katılımcının açık anahtarının kısa bir gösterimidir. İki kişi, yüz yüze görüşme veya doğrulanmış bir telefon görüşmesi gibi başka bir güvenilir kanal üzerinden parmak izlerini karşılaştırabilir.
Eşleşen parmak izleri, beklenen anahtarların kullanıldığına dair ek güven sağlar.
Değişen bir parmak izi otomatik olarak saldırı anlamına gelmez. Meşru bir anahtar sıfırlaması veya cihaz kurtarma işlemi sonrasında da değişebilir. Ancak değişiklik, sessizce göz ardı edilmek yerine görünür ve açıklanabilir olmalıdır.
Yedekleme ve kurtarma, anlık mesaj şifrelemesinden ayrıdır
Bir uygulama canlı mesajları uçtan uca şifrelerken ayrı bir yedekte farklı anahtarlar ve erişim kuralları kullanabilir. Açık metin dışa aktarımı da okunabilir içeriği şifreli görüşmenin dışına taşıyabilir. Nelerin yedeklendiğini, yedeği kimin çözebildiğini ve kurtarma malzemesi kaybolduğunda ne olduğunu sorun.
Livara'nın belgelenmiş kurtarma yedeği, yüklenmeden önce kriptografik olarak mühürlenir ve sohbet geçmişini değil, kimlik malzemesini geri getirir. Hesabın veya kimliğin kurtarılmasının tüm eski görüşmeleri de geri getirdiği sonucuna varmayın. Daha geniş bir değerlendirme için şifreli sohbetleri güvenli yedekleme rehberine bakın.
Özel bir mesajlaşma uygulaması nasıl değerlendirilir?
Bir hizmeti yalnızca “şifreli” veya “güvenli” sözcüklerine bakarak değerlendirmeyin. Somut sorular sorun.
Hangi görüşmeler uçtan uca şifreli?
Korumanın bire bir sohbetleri, grupları, kanalları, aramaları ve ekleri kapsayıp kapsamadığını kontrol edin.
Anahtarlar nerede oluşturuluyor ve saklanıyor?
Anahtarların istemcide oluşturulup oluşturulmadığını ve yedeklerin nasıl korunduğunu anlatan açık bir açıklama arayın.
Sunucu neleri saklıyor?
Sorumlu bir hizmet; mesaj içeriğini yönlendirme bilgilerinden, zaman damgalarından, üyeliklerden, teslim bilgilerinden ve diğer işletim verilerinden ayırmalıdır.
Anahtar değiştiğinde ne oluyor?
Beklenmedik anahtar değişiklikleri görünür olmalıdır. Sessiz değişiklikler, kullanıcının kişilerinin anahtarlarını doğrulama imkânını zayıflatır.
Kurtarma nasıl çalışıyor?
Sağlayıcının anahtarları geri getirip getiremediğini, bir kurtarma sırrının gerekip gerekmediğini ve bu sır kaybolursa ne olduğunu öğrenin.
İddialar bağımsız olarak doğrulanmış mı?
Güvenlik belgeleri, açık protokoller, uzman incelemeleri ve bağımsız denetimler farklı düzeylerde güvence sağlar.
Pazarlama dili tek başına denetim değildir.
Gizlilik için sınırlar açık olmalıdır
Güçlü bir gizlilik açıklaması yalnızca “bize güvenin” demekle yetinmez. Şunları kesin ve sınanabilir biçimde anlatır:
- Neyin şifrelendiği
- Şifrelemenin nerede yapıldığı
- Hangi anahtarların kullanıldığı
- Sunucunun ne aldığı
- Hangi üstverilerin kaldığı
- Hangi görüşme türlerinin kapsam dışında olduğu
- Kurtarmanın tehdit modelini nasıl değiştirdiği
Uçtan uca şifreleme, gizliliğin bütününü açıklamaz. Ancak dikkatli uygulanıp dürüstçe anlatıldığında özel iletişim için kritik bir temel oluşturur.
Pratik bir sonraki adım için 12 soruluk güvenli mesajlaşma kontrol listesini kullanarak gerçekten kullandığınız özellikleri inceleyin: özel sohbetler, gruplar, ekler, aramalar ve yedekler.
Sık sorulan sorular
E2EE neyin kısaltmasıdır?
E2EE, İngilizce “end-to-end encryption”, yani uçtan uca şifreleme ifadesinin kısaltmasıdır. Korunan içerik, bir katılımcı ucunda şifrelenir ve başka bir yetkili uçta çözülür.
İnternet sağlayıcısı E2EE mesajlarını okuyabilir mi?
İnternet sağlayıcısı bir bağlantının varlığını ve ağ düzeyindeki bazı bilgileri görebilir. Ancak doğru şifrelenmiş mesaj içeriğinin iletim sırasında okunabilir açık metin olarak görünmemesi gerekir.
Uçtan uca şifreleme üstverileri gizler mi?
Kendiliğinden gizlemez. Mesajlaşma sistemi; yönlendirme, üyelik, zaman damgası, teslim durumu, şifreli metin boyutu veya hizmetin çalışması için gereken başka bilgileri işlemeye devam edebilir.
E2EE çalınmış, kilidi açık bir telefonu korur mu?
Saldırgan zaten yetkili olan ve kilidi açık bir cihazı kontrol ediyorsa, hiçbir şifreleme protokolü mesajı tamamen koruyamaz. Güçlü cihaz güvenliği yine gereklidir.
Livara'daki tüm görüşmeler uçtan uca şifreli mi?
Livara şu anda doğrudan bire bir mesaj gövdeleri ve medya içerikleri ile uyumlu özel gruplar için E2EE belgeliyor. Bu gruplar LGS1 kullanır ve üyelik değiştiğinde gönderici anahtarları otomatik olarak yenilenir. Kanallar TLS ve kimliği doğrulanmış sunucu tarafı izinler kullanır; kanallar için uçtan uca şifreleme iddiasında bulunulmaz.
Kaybolan bir Livara şifreleme anahtarı kurtarılabilir mi?
Kamuya açık belgeler, gerekli kurtarma sırrı kullanılarak yedeklenmiş kimlik malzemesinin geri getirilmesini anlatır. Bu işlem sohbet geçmişini geri getirmez. Asıl cihazı silmeden veya değiştirmeden önce güncel kurtarma akışını okuyun.
E2EE ile ileri gizlilik aynı şey mi?
Hayır. E2EE, korunan içeriği kimin okuyabilmesi gerektiğini açıklar. İleri gizlilik (forward secrecy), daha sonra gerçekleşen bir anahtar sızıntısının önceki mesajları nasıl etkilediğiyle ilgilidir. Ele geçirilme sonrası güvenlik (post-compromise security) ise belirli koşullarda, bir ele geçirilmenin ardından yeniden koruma sağlanmasını ifade eder. Bu özellikler protokole ve teknik gerçekleştirimine bağlıdır. Örneğin MLS belirtimi, grup anahtarı tasarımı için her ikisini de tanımlar. Bu, her şifreli mesajlaşma uygulamasının bu özellikleri otomatik olarak sağladığı veya MLS kullandığı anlamına gelmez.



