Şifreli depolama dosya baytlarını şifre çözme yetkisinden ayırır; ancak alıcılar, metaveriler ve yerel kopyalar tehdit modelinin parçası olmaya devam eder.
Uçtan uca şifrelenmiş bir ek, sunucuya dosyanın açık metnini vermeden o sunucuda saklanabilir. Yaygın bir tasarım, dosyayı gönderenin cihazında yeni bir içerik anahtarıyla şifreler, şifreli metni yükler ve anahtarı kimliği doğrulanmış şifreli bir mesajın içinde hedeflenen alıcılara gönderir.
Bu ayrım yararlıdır, ancak “sıfır bilgi depolama” eksiksiz bir teknik şartname değildir. Anahtarların, dosya referanslarının, dosya adlarının, erişim kontrollerinin ve indirilen kopyaların nasıl ele alındığını yine de sormanız gerekir.
Ekin yaşam döngüsü
- Dosyayı hazırlayın. Gönderen bir fotoğraf, video veya belge seçer. Metaveri kaldırma veya kod dönüştürme ayrı bir adımdır; şifreleme tek başına EXIF verilerini ya da belge özelliklerini temizlemez.
- Şifreleme malzemesi oluşturun. Güvenli bir uygulama, gerekli anahtar ve nonce malzemesini seçtiği şemaya göre üretir.
- Yüklemeden önce şifreleyin. Depolama hizmeti, özgün içerik yerine şifrelenmiş baytları alır.
- Kimliği doğrulanmış bir referans iletin. Şifreli sohbet mesajı, dosya konumunu belirten bilgi, şifre çözme anahtarı ve ilgili bütünlük metaverileri gibi alıcıların ihtiyaç duyduğu bilgileri taşır.
- Alın ve doğrulayın. Alıcı istemci veri nesnesini alır ve sonucu geçerli içerik olarak kabul etmeden önce kimlik doğrulamasını kontrol eder.
- Yerel kopyaları yönetin. Görüntüleme, dışa aktarma, düzenleme veya galeriye kaydetme, ilk şifreli depolama sınırının dışında kopyalar oluşturabilir.
Anahtar, aynı sağlayıcının altyapısından şifreli bir zarf içinde geçebilir. Buna “bant dışı” demek yanıltıcı olabilir: veri nesnesinin depolanmasından mantıksal olarak ayrıdır, ancak mutlaka bağımsız bir iletişim kanalıyla iletilmez.
Kimliği doğrulanmış şifreleme ne ekler?
Kimliği doğrulanmış şifreleme şeması, gizliliği korur ve doğrulanan kapsam içindeki yetkisiz değişiklikleri tespit eder. NIST'in GCM şartnamesi bu tür bir yapıyı ve gerekliliklerini tanımlar. Anahtar/nonce yönetiminin doğru yapılması ve kimlik doğrulama sonucunun kontrol edilmesi zorunludur; tanınmış bir algoritma adı her uygulamayı güvenli hâle getirmez.
Uygulamanın dosyayı doğru mesaj ve konuşmayla da bağlaması gerekir. Geçerli bir şifreli veri nesnesi, tek başına bu belirli sohbete ait olduğunu kanıtlamaz. Dosya tanımlayıcıları, beklenen boyut, parça sırası ve ek metaverileri uygun bir kimlik doğrulama tasarımı gerektirir.
Depolama hizmeti yine de neler öğrenebilir?
| Bilgi | Yalnızca içerik şifrelemesi bunu gizler mi? |
|---|---|
| Dosyanın özgün baytları | Tasarımın amacı bunları anahtarı olmayan taraflardan gizlemektir |
| Yaklaşık şifreli boyut | Genellikle hayır |
| Yükleme ve indirme zamanları | Genellikle hayır |
| Hangi hesabın dosyayı istediği | Yönlendirme ve erişim kontrolü tasarımına bağlıdır |
| Dosya adı ve açıklaması | Yalnızca protokol bunları da koruyorsa |
| Alıcının kaydettiği bir kopya | Hayır; alıcının zaten açık metne erişimi vardır |
Veri nesneleri şifreli olsa bile erişim kontrolleri önemlidir. İstenmeyen indirmeleri, kötüye kullanımı ve tanımlayıcıların açığa çıkmasını sınırlayabilirler. Şifreleme; yetkilendirmenin, saklama politikalarının veya kullanılabilirliğin yerine geçmez.
Büyük dosyalar bir slogandan fazlasını gerektirir
Büyük dosya tasarımı verileri akış hâlinde işleyebilir veya kimliği doğrulanmış parçalara bölebilir. Bu, bellek kullanımını azaltabilir; ancak parça numaralandırması, son uzunluk, yeniden denemeler ve kesilmelerin nasıl ele alınacağı tanımlanmalıdır. Performans rakamları uydurmayın veya bir dosyayı mesaja koymanın mutlaka “ratchet durumunun şişmesine” neden olduğunu iddia etmeyin; bu sonuçlar uygulamaya bağlıdır.
Yararlı bir test; geçerli bir dosyayı, değiştirilmiş bir baytı, kesilmiş bir indirmeyi, sırası değiştirilmiş bir parçayı ve yetkisiz bir alma girişimini kapsar. Bu testleri yalnızca yetkili bir test ortamında, hassas olmayan dosyalarla çalıştırın. İstemcinin geçersiz veriyi açmadan önce reddedip reddetmediğini kaydedin.
Livara neleri belgeliyor?
Livara'nın güvenlik sayfası, yükleme öncesi şifrelemeyi, korunan oturum içinde taşınan dosya başına rastgele anahtarı ve uyumlu özel gruplar dâhil E2EE'nin etkin olduğu konuşmalarda dosya adları ile açıklamaların korunmasını anlatır. Eski ve uyumsuz gruplar açıkça bu kapsamın dışındadır. Korunan konuşmaları herkese açık yayın kanallarından ayırır. Bunlar belgelenmiş ürün beyanlarıdır; bu makalede yapılmış yeni bir uygulama denetimi değildir.
Tehdit modeli, bir alıcının veya ele geçirilmiş cihazın okunabilir içeriği açığa çıkarabileceğini de kabul eder. Dolayısıyla şifreli depolama, sohbet mesajı silindiğinde bir görüntünün tüm cihazlardan kaybolacağını vaat edemez.
Hassas dosyaları paylaşmadan önce sorulacak sorular
Konuşma türünün E2EE'yi destekleyip desteklemediğini, hedeflenen tüm alıcılara güvenilip güvenilmediğini ve dosyanın kimlik belirleyici metaveriler içerip içermediğini kontrol edin. Galeriye otomatik kaydetmeyi ve bulut fotoğraf yedeklemeyi ayrı ayrı inceleyin. Bir belge için, göndermeden önce yorumların, düzeltme geçmişinin veya gömülü özelliklerin kaldırılıp kaldırılmaması gerektiğini değerlendirin.
Son olarak silme ve kurtarmayı anlayın. Sunucudaki veri nesnesini kaldırmak gelecekteki bir indirmeyi durdurabilir, ancak alıcının mevcut kopyasını geri alamaz. Gerekli anahtarı kaybetmek, geride kalan şifreli dosyayı okunamaz hâle getirebilir. İyi bir ek tasarımı her iki sonucu da açıkça anlatır.
