Bir hesabı, kimliği ve konuşma geçmişini kurtarmak farklı işlemlerdir; ürünün gerçekte hangisini desteklediğini doğrulayın.
Kriptografik kimlik kurtarma, mesajlaşma kimliğinizle ilişkili anahtar materyalini geri getirir. Bu, otomatik olarak bir hesaba yeniden giriş yapmak, tüm konuşmaları geri yüklemek veya yerine kullanılan cihazın güvenli olduğunu kanıtlamakla aynı şey değildir.
Şifreli bir anahtar yedeği, sunucunun paketi açmak için gereken sırra sahip olmadan kurtarılabilir bir paket saklamasını sağlayabilir. Bu tasarımın kullanıcıyı koruyup korumadığı; anahtar üretimine, kimlik doğrulamaya, kurtarma sırrının korunmasına ve istemcinin kurtarılan kimliği nasıl ele aldığına bağlıdır.
“Kurtarma” denilen üç farklı şey
| Kurtarma amacı | Geri getirilmesi veya yetkilendirilmesi gereken |
|---|---|
| Hesaba erişim | Giriş yapma ve hizmeti kullanma izni |
| Kriptografik kimlik | Uygun özel anahtarlar veya kimliği doğrulanmış yeni bir kimlik |
| Sohbet geçmişi | Mesaj verileri ve bunları okumak için gereken anahtarlar veya durum bilgisi |
Başarılı bir giriş, diğer ikisinin gerçekleştiğini kanıtlamaz. Benzer şekilde bir kimlik anahtarı, kasıtlı olarak silinmiş eski mesaj anahtarlarını veya artık var olmayan bir geçmiş dosyasını mutlaka yeniden oluşturmaz.
Bir ürünün kurtarma özelliğine güvenmeden önce gerçekte hangi amacı vaat ettiğini yazın.
Şifreli kimlik yedeği nasıl çalışabilir?
Tipik bir tasarım, kimlik materyalini güvenilir bir cihazda üretir, yedeği ayrı bir kurtarma sırrıyla şifreler ve hizmette yalnızca korunan paketi saklar. Yerine kullanılan cihaz paketi alır ve kurtarma sırrını yerel olarak kullanır.
Sunucu yine de pakete erişimi kontrol edebilir, istekleri gözlemleyebilir, verileri vermeyebilir veya eski bir sürümü döndürebilir. Kimliği doğrulanmış şifreleme ve sürüm/kimlik bağlaması, belirli kurcalama risklerini ele almaya yardımcı olur; kullanılabilirlik ve eski sürüme döndürme durumlarının yönetimi için ayrı bir tasarım gerekir. “Sunucuda şifreli” ifadesi, sunucunun ele geçirildiği her senaryoya eksiksiz bir yanıt değildir.
Rastgele, yüksek entropili bir kurtarma anahtarı ile insanın seçtiği bir parola da farklı girdilerdir. HKDF’yi herhangi bir zayıf parola ifadesini güçlü bir sırra dönüştüren bir yöntem olarak tanımlamayın. RFC 5869, HKDF’nin rolünü ele alır ve onu hesaplama maliyetini artırarak parola güçlendirmeden ayırır.
Livara’nın v7 belgeleri ne söylüyor?
Livara’nın güvenlik sayfası, P-256 anahtar anlaşması/imzalama anahtarlarının ve ML-KEM tohumunun yüklemeden önce cihazda rastgele 256 bitlik bir kurtarma anahtarıyla şifrelendiğini belirtiyor. v7 biçimi; algoritma takımı, kimlik dönemi ve nesil dahil bilgilerin kimliğini doğrular.
Aynı sayfa açıkça şunu söylüyor: sohbet geçmişini değil, kimliği geri getirir. Ayrıca doğru giriş parolasının tek başına şifreli anahtar yedeğini açmaya yetmediğini; kurtarma ifadesinin temsil ettiği kurtarma anahtarının gerektiğini belirtiyor.
Bunlar yayımlanmış ürün iddialarıdır; yedek biçiminin veya her kurtarma yolunun yeni bir denetimi değildir. Daha genel tehdit modeli, kapsamı daha dar olan bu kurtarma açıklamasıyla birlikte okunmalıdır.
SRP nerede devreye girer?
SRP kimlik doğrulama modeli, parola tabanlı girişle ilgilidir. Amaçlanan protokol alışverişinde parolanın kendisini iletmekten kaçınabilir; ancak bir anahtar yedeğinin içeriğini tanımlamaz veya her kurtarma anahtarını otomatik olarak türetmez.
Sunucu tarafındaki doğrulayıcısının yine de korunması gerekir. RFC 5054, bölüm 3.3, bir doğrulayıcı çalındıktan sonra parola tahmini riskini açıklar. “Sunucu bu alışverişte parolayı almaz” ifadesini, “sunucu ihlali işe yarar hiçbir şeyi açığa çıkaramaz” şeklinde yorumlamayın.
Hesap oturumları, kurtarma paketleri, operasyonel üst veriler ve istemci yazılımı; farklı hata biçimlerine sahip ayrı varlıklardır.
Güvenli kurtarma hazırlığı kontrol listesi
- Özelliğin tam olarak hangi verileri geri getirdiğini ve hangilerini getirmediğini doğrulayın.
- Kurtarma sırrını, telefonun kaybolmasının tek kopyanın da kaybolması anlamına gelmeyeceği bir yerde tutun.
- Sırrı bir mesaja, destek talebine veya herkese açık ekran görüntüsüne koymaktan kaçının.
- Sırrın saklandığı yeri koruyun; onu ele geçiren biri, ilgili yedeği ve erişimi de elde ederse önemli yetenekler kazanabilir.
- Çalışan tek cihazı silmeden veya değiştirmeden önce resmî kurtarma yönergelerini inceleyin.
- Yalnızca desteklenen prosedürlerle, önemli verilerin tek kopyasını yok etmeden test yapın.
Kurtarmadan sonra bağlı cihazları ve oturumları ayrıca inceleyin. Kurtarılan kimlik materyali eski bir cihazın yetkisini otomatik olarak iptal etmez. Kriptografik kimlik değişirse hassas bilgi paylaştığınız kişiler, bağımsız olarak güvenilen bir yol üzerinden yeni anahtarı doğrulamalıdır.
Kurtarma ifadesi kaybolursa
Destek ekibinin, sistemin saklamamak üzere tasarlandığı bir sırrı yeniden oluşturabileceğini varsaymayın. Aynı şekilde, unutulan her hesap parolasının tüm yerel mesajların çoktan kaybolduğu anlamına geldiğini düşünmeyin. Sonuçlar; elde kalan cihazlara, mevcut yedeklere ve ürünün belgelenmiş kurallarına bağlıdır.
Yararlı soru somuttur: “Hangi sır veya kopya eksik ve hangi kurtarma amacı hâlâ mümkün?”. Bu, kurtarmanın zahmetsiz ya da imkânsız olduğuna dair genel bir vaatten daha güvenli bir yanıt verir.
