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.Protectdeğişiklik göstermedi, ancak AAD sistem tarafından oluşturulur ve üç bileşenden oluşur:

1. Veri koruma sisteminin bu sürümünü tanımlayan 32 bit magic header 09 F0 C9 F0.

2. 128 bit anahtar kimliği.

3. 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.Encryptaş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_Htü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_Mbir 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.