ASP.NET Core'da alt anahtar türetme ve kimliği doğrulanmış şifreleme
Anahtar kademesindeki çoğu anahtar bir tür entropi içerir ve "CBC modu şifreleme + HMAC doğrulaması" veya "GCM şifrelemesi + doğrulama" şeklinde algoritmik bilgilere sahip olacaktır. Bu gibi durumlarda, katıştırılmış entropiyi bu anahtar için ana anahtarlama malzemesi (veya KM) olarak adlandırıyoruz ve gerçek şifreleme işlemleri için kullanılacak anahtarları türetmek için bir anahtar türetme işlevi gerçekleştiriyoruz.
Dekont
Anahtarlar soyut olur ve özel bir uygulama aşağıdaki gibi davranmayabilir. Anahtar, yerleşik fabrikalarımızdan birini kullanmak yerine kendi uygulamasını IAuthenticatedEncryptor
sağlıyorsa, bu bölümde açıklanan mekanizma artık geçerli değildir.
Ek kimliği doğrulanmış veri ve alt anahtar türetme
Arabirim, IAuthenticatedEncryptor
kimliği doğrulanmış tüm şifreleme işlemleri için temel arabirim görevi görür. Yöntemi Encrypt
iki arabellek alır: plaintext ve additionalAuthenticatedData (AAD). Düz metin içeriği akışı, çağrısında IDataProtector.Protect
değişiklik göstermedi, ancak AAD sistem tarafından oluşturulur ve üç bileşenden oluşur:
Veri koruma sisteminin bu sürümünü tanımlayan 32 bit magic header 09 F0 C9 F0.
128 bit anahtar kimliği.
Bu işlemi gerçekleştiren öğesini oluşturan
IDataProtector
amaç zincirinden oluşturulan değişken uzunlukta bir dize.
AAD, üç bileşenin demetinde benzersiz olduğundan, tüm şifreleme işlemlerimizde KM'nin kendisini kullanmak yerine KM'den yeni anahtarlar türetmek için bunu kullanabiliriz. öğesine yapılan her çağrı için IAuthenticatedEncryptor.Encrypt
aşağıdaki anahtar türetme işlemi gerçekleşir:
( K_E, K_H ) = SP800_108_CTR_HMACSHA512(K_M, AAD, contextHeader || keyModifier)
Burada, NIST SP800-108 KDF'yi Sayaç Modunda çağırıyoruz (bkz . NIST SP800-108, Sn. 5.1) aşağıdaki parametrelerle:
Anahtar türetme anahtarı (KDK) =
K_M
PRF = HMACSHA512
label = additionalAuthenticatedData
context = contextHeader || keyModifier
Bağlam üst bilgisi değişken uzunluktadır ve temelde ve K_H
türetdiğimiz K_E
algoritmaların parmak izi olarak görev görür. Anahtar değiştirici, her çağrısı Encrypt
için rastgele oluşturulan 128 bitlik bir dizedir ve KDF'ye yapılan diğer tüm girişler sabit olsa bile, KE ve KH'nin bu özel kimlik doğrulama şifreleme işlemi için benzersiz olduğundan emin olma olasılığı yüksektir.
CBC modu şifreleme + HMAC doğrulama işlemleri için simetrik | K_E |
blok şifreleme anahtarının uzunluğudur ve | K_H |
HMAC yordamının özet boyutudur. GCM şifreleme + doğrulama işlemleri için, | K_H | = 0
.
CBC modu şifreleme + HMAC doğrulaması
Yukarıdaki mekanizma aracılığıyla oluşturulduktan sonra K_E
, rastgele bir başlatma vektöru oluşturur ve düz metni çözmek için simetrik blok şifreleme algoritmasını çalıştırırız. Başlatma vektöru ve şifreleme metni daha sonra HMAC yordamı aracılığıyla çalıştırılır ve MAC'i üretmek için anahtarla K_H
başlatılır. Bu işlem ve dönüş değeri aşağıda grafik olarak gösterilir.
output:= keyModifier || iv || E_cbc (K_E,iv,data) || HMAC(K_H, iv || E_cbc (K_E,iv,data))
Dekont
Uygulama, IDataProtector.Protect
çağırana döndürmeden önce çıkışa sihirli üst bilgi ve anahtar kimliğini ekler. Sihirli üst bilgi ve anahtar kimliği örtük olarak AAD'nin bir parçası olduğundan ve anahtar değiştirici KDF'ye giriş olarak beslendiğinden, döndürülen son yükün her baytının KIMLIĞI MAC tarafından doğrulanır.
Galois/Sayaç Modu şifreleme + doğrulama
Yukarıdaki mekanizma aracılığıyla oluşturulduktan sonra K_E
rastgele bir 96 bit nonce oluşturur ve düz metni çözmek ve 128 bit kimlik doğrulama etiketini üretmek için simetrik blok şifreleme algoritmasını çalıştırırız.
output := keyModifier || nonce || E_gcm (K_E,nonce,data) || authTag
Dekont
GCM, AAD kavramını yerel olarak desteklese de AAD'yi yalnızca özgün KDF'ye besliyoruz ve AAD parametresi için GCM'ye boş bir dize geçirmeyi tercih ediyoruz. Bunun nedeni iki kattır. İlk olarak, çevikliği desteklemek için asla doğrudan şifreleme anahtarı olarak kullanmak K_M
istemiyoruz. Ayrıca GCM, girişlerine çok katı benzersizlik gereksinimleri uygular. GCM şifreleme yordamının aynı (anahtar, nonce) çifti olan iki veya daha fazla farklı giriş veri kümesinde çağrılma olasılığı 2^-32'yi aşmamalıdır. Düzeltirsek K_E
, 2^-32 sınırının afoul değerini çalıştırmadan önce 2^32'den fazla şifreleme işlemi gerçekleştiremeyiz. Bu çok fazla sayıda işlem gibi görünebilir, ancak yüksek trafikli bir web sunucusu yalnızca birkaç gün içinde 4 milyar istekten geçebilir ve bu anahtarlar için normal yaşam süresi içinde kullanılabilir. 2^-32 olasılık sınırıyla uyumlu kalmak için 128 bit anahtar değiştirici ve 96 bit nonce kullanmaya devam ediyoruz ve bu da herhangi K_M
bir için kullanılabilir işlem sayısını kökten genişletir. Tasarımın basitliği için CBC ile GCM işlemleri arasında KDF kod yolunu paylaşırız ve AAD zaten KDF'de dikkate alındığından bunu GCM yordamına iletmeye gerek yoktur.
ASP.NET Core