İkinci cihazını ekle. Ama sunucu düz metni hiç görmesin.

Uçtan uca şifrelemenin en zor kullanıcı deneyimi sorusu şu: telefonundaki mesajları bilgisayarında nasıl okuyacaksın? Cevabın kolay yolu, şifrelemenin tamamını iptal ediyor.

This post is in Turkish.

Uçtan uca şifreli bir üründe en zor mühendislik sorusu şifreleme değil. Kullanıcının ikinci cihazı.

Telefonunda konuşuyorsun, bilgisayarını açıyorsun, aynı sohbeti görmek istiyorsun. Bu, şifresiz bir üründe düşünmeye bile değmeyecek kadar basit. Şifreli bir üründe ise ürünün bütün vaadinin sınandığı yer.

Çünkü kolay çözüm hazır: anahtarı sunucuda tut, yeni cihaza gönder. Bunu yaptığın an "biz de okuyamıyoruz" cümlesi yalan oluyor.

Cihaz bir üye

Kurgunun temelinde şu var: cihaz, kullanıcının bir uzantısı değil — kendi başına bir üye.

Her cihazın kendi anahtar çifti var ve gruba kendi kimliğiyle katılıyor. Yani "Doğan" grubun üyesi değil; "Doğan'ın telefonu" ve "Doğan'ın dizüstü bilgisayarı" ayrı ayrı üye.

Bu, ilk bakışta karmaşık görünüyor ama bir sürü şeyi doğal olarak çözüyor. Bir cihazı kaybettiğinde onu gruptan çıkarıyorsun, diğerleri devam ediyor. Çıkarılan cihaz sonraki mesajları çözemiyor — çünkü grup yeni bir döneme geçiyor ve o dönemin anahtarı ona hiç gitmiyor.

MLS'in üye ekleme–çıkarma modeli tam olarak bunun için var. Cihazı üye olarak modellediğinde, çok cihaz desteği ayrı bir mekanizma olmaktan çıkıp zaten sahip olduğun mekanizmanın bir kullanımı hâline geliyor.

Yeni cihaz kendini nasıl tanıtır

Asıl soru şu: yeni cihaz gruba katılmak için mevcut cihazından onay almalı, ama bu onay sunucunun okuyabileceği bir şey olmamalı.

Buradaki standart çözüm, iki cihazın kısa süreli bir kanal üzerinden birbirini doğrulaması. Mevcut cihazda bir kod veya QR çıkıyor, yeni cihaz onu okuyor, ve iki taraf birbirinin anahtarının parmak izini karşılaştırıyor. Sunucu bu alışverişte sadece taşıyıcı — içeriği okuyamıyor, ve araya girmeye çalışırsa parmak izleri tutmuyor.

Kritik nokta doğrulamanın kullanıcıya görünür olması. Kod eşleşmesini kullanıcı gözüyle onaylıyorsa, araya giren bir sunucu yakalanıyor. Onay tamamen otomatikse, kullanıcı neyi onayladığını bilmiyor.

Uçtan uca şifrelemede kullanıcıya gösterilen doğrulama adımı bir sürtünme değil. Güvenlik modelinin kendisi.

Geçmiş mesajlar meselesi

Sonra gelen soru: yeni cihaz eski mesajları görecek mi?

İki cevap da savunulabilir ve bu bir ürün kararı.

Görmesin dersen model temiz kalıyor — her cihaz katıldığı andan itibaren okuyor, geçmiş hiç aktarılmıyor. Ama kullanıcı bilgisayarını açtığında boş bir sohbet görüyor ve bunu bir hata sanıyor.

Görsün dersen, geçmişi bir yerden aktarman gerekiyor. Doğru yol sunucudan değil, mevcut cihazdan aktarmak: eski cihaz geçmişi yeni cihazın anahtarıyla şifreleyip gönderiyor. Sunucu yine sadece taşıyor.

Bunun bedeli, iki cihazın aynı anda çevrimiçi olması gerektiği. Ve kullanıcıya bunu anlatmak zorundasın — "eski telefonunu açık tut" cümlesi, hiçbir ürün ekibinin yazmak istemediği bir yönerge ama alternatifi anahtarı sunucuya vermek.

Yedek: kaybettiğinde ne olacak

En zor senaryo tek cihazın kaybolması. Onay verecek başka cihaz yok.

Burada seçenek şifreli yedek: anahtar malzemesi, yalnızca kullanıcının bildiği bir parola veya kurtarma koduyla şifrelenip saklanıyor. Sunucu şifreli yığını tutuyor, açamıyor.

Bunun dürüst tarafı şu — kurtarma kodunu kaybeden kullanıcı geçmişini kaybediyor. Bu bir kusur değil, tasarımın sonucu. Kurtarabildiğin her senaryo, sunucunun da kurtarabileceği bir senaryodur.

Ve ürün tarafında yapılması gereken şey bunu gizlemek değil, kurtarma kodunu kurulum akışının atlanamayan bir adımı hâline getirmek.