Kriptografik kimliği kurtarmak, hesaba yeniden giriş yapmak ve sohbet geçmişini kurtarmak üç farklı işlemdir. Livara güvenlik belgelerine göre v7 biçimi kriptografik kimliği kurtarmak için kullanılır; bu biçim tek başına sohbet geçmişini geri getirmez.
Ayrıca bu mimari “hiçbir bulut yedeği yok” diye tanımlanmamalıdır. Mevcut belge, kimlik materyalinin cihazda şifrelendiğini ve ardından şifreli yedek olarak yüklendiğini söylüyor. Önemli ayrım, sunucuda okunabilir anahtar saklamak ile açılması için kurtarma anahtarı gereken şifreli bir kopya saklamak arasındadır.
Aynı anahtarla açılmayan üç kapı
| İşlem | Amaç | Neden yeterli değildir? |
|---|---|---|
| Hesaba giriş | Hizmet hesabına erişim hakkını kanıtlamak | Önceki mesajları çözmek için gereken anahtarı mutlaka sağlamaz |
| Kimlik kurtarma | Kriptografik kimlik materyaline yeniden erişmek | Tek başına tüm mesajların var olduğunu veya kurtarıldığını kanıtlamaz |
| Geçmiş kurtarma | Gerekli mesaj ve ekleri geri getirmek | Anahtarın yanı sıra verilerin kendisini ve desteklenen bir kurtarma yöntemini gerektirir |
Bu ayrım pahalı bir hatayı önler: giriş parolasını bilmenin tüm konuşmaları geri getirmeye yeteceğini düşünerek eski telefonu silmek.
v7 belgeleri tam olarak ne diyor?
Livara güvenlik sayfası, P-256 anahtar anlaşması ve imza anahtarları ile ML-KEM tohumunun cihazda, rastgele bir 256 bitlik kurtarma anahtarı altında şifrelendiğini açıklar. v7 biçiminin açıklamasında algoritma takımı, kimlik dönemi ve nesil de doğrulanır. Bu açıklama üreticinin belgesidir; tek başına uygulamanın bağımsız denetimi sayılmaz.
Livara tehdit modeli, anahtar yedeğini açmak için kurtarma ifadesinin gerekli olduğunu belirtir. Bu açıklamadan ifadenin anahtara dönüştürülmesindeki kesin algoritma veya tüm anahtarların doğrudan yeniden oluşturulduğu sonucu tahmin edilmemelidir. Uygulamadaki ayrıntılar, uygulama sürümü ve o sürümün kılavuzuyla eşleştirilmelidir.
Bir türetme işlevi neden zayıf bir ifadeyi güçlü yapmaz?
Bir işlevin çıktı uzunluğu, girdinin tahmin edilemezlik düzeyiyle aynı şey değildir. RFC 5869, HKDF'nin mevcut entropiyi yoğunlaştırdığını ama artırmadığını açıkça belirtir. Bu nedenle herhangi bir ifadenin HKDF'den geçirilince kendiliğinden tam 256 bit güvenlik kazandığı iddia edilemez.
Uygulamanın resmî akışında üretilen ifadeyi keyfî olarak kısaltmayın, yeniden yazmayın veya tahmin edilebilir bir cümleyle değiştirmeyin. Hiçbir kişiye, destek botuna veya bilinmeyen forma göndermeyin.
Telefonu değiştirmeden veya silmeden önce
- Uygulamada neyin yedeklendiğini doğrulayın: kimlik, geçmiş veya ayrı yöntemlerle ikisi birden.
- Kurtarma ifadesini aynı telefondan bağımsız, güvenli bir yerde saklayın; başkalarının ona erişmesini ciddi bir risk olarak görün.
- Kurtarma için mevcut sürümün kılavuzunu okuyun. Yalnızca “giriş başarılı” mesajını görmek tam kurtarma sonucu değildir.
- Kurtarmayı denemek için desteklenen bir yöntem varsa önce hassas olmayan verilerle ve mevcut tek kopyayı silmeden deneyin.
- Aktarımdan sonra gereken konuşmaları ve dosyaları kontrol edin; ancak bundan sonra eski cihazı bırakmaya karar verin.
Kurtarma ifadem yoksa ne olur?
Hâlâ yetkili bir cihazınız varsa yalnızca o uygulamada mevcut olan resmî yolları inceleyin; sürümü görmeden yeni bir yedek oluşturulabileceğini varsaymayın. Hem cihaz hem ifade kaybedildiyse Livara belgesi anahtar kurtarmayı vaat etmez. Hiçbir “garantili şifre çözme” hizmetini bu sınırın yerine koymayın.
Hesap taşıma planına “Hangi veri, hangi anahtarla ve hangi yedekten geri gelecek?” sorusuyla başlayın; yeniden giriş yapmanın tüm sohbetlerin geri gelmesi anlamına geldiği varsayımıyla değil.
