AES-GCM, bir mesajın gizliliğini koruyabilir ve yetkisiz değişiklikleri saptayabilir. Tek başına, diğer yönlerden geçerli bir mesajın daha önce işlenip işlenmediğini alıcıya söylemez.
Üç gereksinim kolayca birbirine karıştırılır: şifreleme için benzersiz anahtar/nonce çiftleri, mesajın ve bağlamının doğrulanması ve protokol düzeyinde tekrarların ele alınması. HKDF anahtar türetmeye yardımcı olabilir, ancak üçünü birden otomatik olarak karşılamaz.
Nonce’un yeniden kullanılması ve tekrar saldırısı farklı olaylardır
| Olay | Ne olur? | Gereken koruma |
|---|---|---|
| Şifreleme sırasında nonce’un yeniden kullanılması | Farklı açık metinler aynı GCM anahtarı ve nonce ile şifrelenir | Güvenilir bir anahtar/nonce tahsis stratejisi |
| Kurcalama | Şifreli metin veya doğrulanan bağlam değiştirilir | Doğrulamalı şifre çözme ve başarısızlıkta reddetme |
| Tekrar oynatma | Daha önce geçerli olan şifreli mesaj yeniden teslim edilir | Yinelenen veya eskimiş mesajları tanıyan durum ve uygulama kuralları |
| Sıralamanın değişmesi | Geçerli mesajlar farklı bir sırayla ulaşır | Protokolün tanımladığı sıralama ve sınırlı sıra dışı işleme |
Tekrar oynatılan şifreli metin hâlâ geçerli bir doğrulama etiketine sahip olabilir. Hiçbir şey değiştirilmemiştir. Bu yüzden her yinelenen mesajın AES-GCM doğrulamasında otomatik olarak başarısız olduğunu söylemek yanlıştır. RFC 5116, AEAD arayüzünü tekrar önleme hizmetlerinden açıkça ayırır.
Anahtar ve nonce çifti neden tekrarlanmamalıdır?
GCM nonce’unun gizli olması gerekmez, ancak belirli bir anahtar altında şemanın benzersizlik gereksinimlerini karşılaması gerekir. 96 bitlik, yani 12 baytlık nonce yaygındır; bu uzunluğu seçmek doğru üretimi garanti etmez.
Farklı açık metinler için aynı anahtarı ve nonce’u yeniden kullanmak, şifreleme anahtar akışını yeniden kullanarak açık metinler arasındaki ilişkileri açığa çıkarır. Ayrıca özgünlüğü zedeleyebilir ve sahteciliğe olanak tanıyabilir. Etkisi ciddidir, ancak her eski anahtarı veya hesaptaki her mesajı otomatik olarak açığa çıkardığı şeklinde anlatılmamalıdır. Etkilenen kapsam, yeniden kullanılan anahtara ve protokole bağlıdır.
NIST SP 800-38D, GCM’yi ve gereksinimlerini tanımlar. Uygulamalar, “şu kadar mesaja kadar güvenli” gibi basitleştirilmiş bir kestirme yerine geçerli çağrı sınırlarına ve nonce üretim kurallarına uymalıdır.
HKDF ne sağlar?
RFC 5869’da tanımlanan HKDF, çıkarma ve genişletme aşamalarını kullanarak gizli girdi malzemesinden anahtar malzemesi türetir. Protokoller, farklı amaçlara yönelik anahtarları ayırmak için bağlam etiketleri ve farklı girdiler kullanabilir.
HKDF deterministiktir. Çöken veya eski durumuna döndürülen bir istemci aynı durumu ve girdileri tekrarlarsa aynı çıktıyı yeniden türetebilir. Dolayısıyla bir tasarıma HKDF eklemek nonce’un yeniden kullanılmasını imkânsız kılmaz.
Mesaj başına anahtarlar, tek bir anahtarla korunan içerik miktarını azaltabilir; ancak güvenli durum ilerlemesi, anahtar ayrımı ve silme hâlâ önemlidir. Gerçekten farklı anahtarlar altında aynı nonce değerini kullanmak, bir anahtar/nonce çiftini tekrarlamakla aynı hata değildir; protokol anahtarların gerçekten farklı olduğunu sağlamalıdır.
Tekrar koruması protokolün sorumluluğundadır
Alıcı mesaj tanımlayıcılarını, sıra konumlarını, oturum dönemlerini veya tüketilmiş ratchet anahtarlarını izleyebilir. Saldırganın eski bir mesajı yeni olarak yeniden etiketleyememesi için ilgili alanlar doğrulanmalıdır.
Ardından uygulama, yinelenen mesajın ne anlama geldiğine karar vermelidir. Yinelenen bir sohbet balonu göstermek rahatsız edicidir; aynı işlemi iki kez yürütmek daha ciddi olabilir. Ağ yeniden denemeleri normaldir; bu nedenle kriptografik kontrollerin yanında çoğu zaman idempotent işleme de gerekir.
Protokol bu davranışı belirtmedikçe her geçerli mesajın kesinlikle sırayla ulaşmasını şart koşmayın. Mobil istemciler düzenli olarak yeniden bağlanır, yeniden dener ve gecikmiş mesajlar alır. Güvenli işleme, meşru bir geç mesajı zaten tüketilmiş veya yanlış bağlama ait bir mesajdan ayırır.
Koruma iddiasından önce neler test edilmeli?
- Nonce tahsis edildikten ancak gönderim kaydedilmeden önce yeniden başlatın: tahsis tekrarlanabilir mi?
- Daha eski bir durum anlık görüntüsünü geri yükleyin: anahtarlar, sayaçlar veya tekrar kayıtları geriye alınabilir mi?
- İki çalışandan veya cihazdan eşzamanlı gönderin: anahtar/nonce alanları birbirinden ayrılmış mı?
- Aynı geçerli mesajı iki kez teslim edin: uygulama işlemi bir kez mi yürütülüyor?
- Oturum tanımlayıcısını veya başlığı değiştirin: bağlam kriptografik olarak bağlanmış mı?
- Geçerli mesajları sıra dışı teslim edin: desteklenen gecikmeler eski durum kabul edilmeden işleniyor mu?
Doğrulamalı şifre çözme API’leri, açık metni uygulamaya yalnızca başarılı doğrulama sonrasında döndürmelidir. Bu bir arayüz gereksinimidir; hiçbir uygulamanın içeride geçici bir açık metin arabelleği hesaplamadığı iddiası değildir.
Livara’nın iddialarını doğru okumak
Livara’nın güvenlik belgeleri, AES-256-GCM’yi, mesaj başına zincirleri ve LVR1/LGS1 bağlamını belirtir. Bu kriptografik yapı taşları tek başlarına doğru çökme kurtarmasını, nonce tahsisini veya tekrarların reddedilmesini kanıtlamaz. Bu tür iddialar sürümlendirilmiş protokol ayrıntıları ve test kanıtları gerektirir.
Güçlü bir tasarım her görevi açıkça atar: anahtar türetme amaçlanan anahtarları oluşturur, AEAD içeriği ve bağlamı doğrular, durum tutan protokol mantığı ise geçerli bir mesajın şu anda kabul edilebilir olup olmadığına karar verir.
