ASP.NET Core'da bağlam üst bilgileri
Arka plan ve teori
Veri koruma sisteminde "anahtar", kimliği doğrulanmış şifreleme hizmetleri sağlayabilen bir nesne anlamına gelir. Her anahtar benzersiz bir kimlikle (GUID) tanımlanır ve algoritmik bilgiler ve entropik malzeme ile birlikte taşır. Her anahtarın benzersiz bir entropi taşıması amaçlanmıştır, ancak sistem bunu zorunlu kılamaz ve anahtar kademesindeki mevcut bir anahtarın algoritmik bilgilerini değiştirerek anahtar halkasını el ile değiştirebilecek geliştiricileri de hesaba katmanız gerekir. Bu gibi durumlarda güvenlik gereksinimlerimizi karşılamak için veri koruma sistemi, birden çok şifreleme algoritmasında tek bir entropik değeri güvenli bir şekilde kullanmaya olanak tanıyan şifreleme çevikliği kavramına sahiptir.
Şifreleme çevikliğini destekleyen sistemlerin çoğu, yükün içindeki algoritma hakkında bazı tanımlayıcı bilgiler ekleyerek bunu yapar. Algoritmanın OID'i genellikle bunun için iyi bir adaydır. Bununla birlikte, karşılaştığımız bir sorun, aynı algoritmayı belirtmenin birden çok yolu olmasıdır: "AES" (CNG) ve yönetilen Aes, AesManaged, AesCryptoServiceProvider, AesCng ve RijndaelManaged (belirli parametrelere göre) sınıfların hepsi aslında aynı şeydir ve bunların tümünün doğru OID ile eşlemesini korumamız gerekir. Bir geliştirici özel bir algoritma (hatta başka bir AES! uygulaması) sağlamak isterse OID'sini bize söylemeleri gerekir. Bu ek kayıt adımı, sistem yapılandırmasını özellikle zahmetli hale getirir.
Geri adım atarak, soruna yanlış yönden yaklaştığımıza karar verdik. Bir OID size algoritmanın ne olduğunu söyler, ancak bunu gerçekten önemsemiyoruz. İki farklı algoritmada tek bir entropik değeri güvenli bir şekilde kullanmamız gerekiyorsa algoritmaların gerçekte ne olduğunu bilmemiz gerekmez. Bizim asıl önemsediğimiz onların nasıl davrandıklarıdır. Herhangi bir iyi simetrik blok şifreleme algoritması aynı zamanda güçlü bir pseudorandom permütasyonudur (PRP): girişleri düzeltin (anahtar, zincirleme modu, IV, düz metin) ve şifre metni çıkışı, aynı girişler verilen diğer simetrik blok şifreleme algoritmalarından büyük olasılıkla farklı olacaktır. Benzer şekilde, herhangi bir iyi anahtarlı karma işlevi de güçlü bir sözde anahtarlama işlevidir (PRF) ve sabit bir giriş kümesi verildiğinde çıkışı diğer anahtarlanmış karma işlevlerden aşırı derecede ayrı olacaktır.
Bağlam üst bilgisi oluşturmak için bu güçlü PRP'ler ve PRF'ler kavramını kullanırız. Bu bağlam üst bilgisi temelde belirli bir işlem için kullanılan algoritmalar üzerinde kararlı bir parmak izi işlevi görür ve veri koruma sisteminin ihtiyaç duyduğu şifreleme çevikliğini sağlar. Bu üst bilgi yeniden üretilebilir ve daha sonra alt anahtar türetme işleminin bir parçası olarak kullanılır. Temel algoritmaların çalışma modlarına bağlı olarak bağlam üst bilgisini oluşturmanın iki farklı yolu vardır.
CBC modu şifreleme + HMAC kimlik doğrulaması
Bağlam üst bilgisi aşağıdaki bileşenlerden oluşur:
[16 bit] "CBC şifrelemesi + HMAC kimlik doğrulaması" anlamına gelen bir işaretleyici olan 00 00 değeri.
[32 bit] Simetrik blok şifreleme algoritmasının anahtar uzunluğu (bayt cinsinden, büyük endian).
[32 bit] Simetrik blok şifreleme algoritmasının blok boyutu (bayt cinsinden, büyük endian).
[32 bit] HMAC algoritmasının anahtar uzunluğu (bayt cinsinden, büyük endian). (Şu anda anahtar boyutu her zaman özet boyutuyla eşleşir.)
[32 bit] HMAC algoritmasının özet boyutu (bayt cinsinden, büyük endian).
EncCBC(K_E, IV, "")
, boş bir dize girişi verildiğinde simetrik blok şifreleme algoritmasının çıkışıdır ve BURADA IV sıfır vektördür. yapısıK_E
aşağıda açıklanmıştır.MAC(K_H, "")
, boş bir dize girişi verildiğinde HMAC algoritmasının çıkışıdır. yapısıK_H
aşağıda açıklanmıştır.
İdeal olarak ve K_H
için K_E
sıfır vektörleri geçirebiliriz. Ancak, sıfır vektör gibi basit veya yinelenebilir bir desen kullanmayı engelleyen herhangi bir işlemi (özellikle DES ve 3DES) gerçekleştirmeden önce temel algoritmanın zayıf anahtarların varlığını denetlemesi durumundan kaçınmak istiyoruz.
Bunun yerine NiST SP800-108 KDF'yi Sayaç Modunda (bkz . NIST SP800-108, Sn. 5.1) sıfır uzunluklu anahtar, etiket ve bağlam ile kullanırız ve temel prf olarak HMACSHA512. Çıktı baytlarını türetiyoruz | K_E | + | K_H |
, ardından sonucu K_E
ve K_H
kendilerine ayırıyoruz. Matematiksel olarak, bu aşağıdaki gibi temsil edilir.
( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")
Örnek: AES-192-CBC + HMACSHA256
Örnek olarak, simetrik blok şifreleme algoritmasının AES-192-CBC ve doğrulama algoritmasının HMACSHA256 olduğu durumu göz önünde bulundurun. Sistem aşağıdaki adımları kullanarak bağlam üst bilgisini oluşturur.
İlk olarak, belirtilen algoritmalara göre , where | K_E | = 192 bits
ve | K_H | = 256 bits
izin verin( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")
. Bu, aşağıdaki örnekte ve'ye K_E = 5BB6..21DD
K_H = A04A..00A9
yol açar:
5B B6 C9 83 13 78 22 1D 8E 10 73 CA CF 65 8E B0
61 62 42 71 CB 83 21 DD A0 4A 05 00 5B AB C0 A2
49 6F A5 61 E3 E2 49 87 AA 63 55 CD 74 0A DA C4
B7 92 3D BF 59 90 00 A9
Ardından, AES-192-CBC için yukarıdaki gibi ve K_E
verilen IV = 0*
işlemEnc_CBC (K_E, IV, "")
.
result := F474B1872B3B53E4721DE19C0841DB6F
Ardından, yukarıdaki gibi verilen K_H
HMACSHA256 için işlem MAC(K_H, "")
yapın.
result := D4791184B996092EE1202F36E8608FA8FBD98ABDFF5402F264B1D7211536220C
Bu, aşağıdaki tam bağlam üst bilgisini oluşturur:
00 00 00 00 00 18 00 00 00 10 00 00 00 20 00 00
00 20 F4 74 B1 87 2B 3B 53 E4 72 1D E1 9C 08 41
DB 6F D4 79 11 84 B9 96 09 2E E1 20 2F 36 E8 60
8F A8 FB D9 8A BD FF 54 02 F2 64 B1 D7 21 15 36
22 0C
Bu bağlam üst bilgisi, kimliği doğrulanmış şifreleme algoritması çiftinin parmak izidir (AES-192-CBC şifreleme + HMACSHA256 doğrulama). Yukarıda açıklandığı gibi bileşenler şunlardır:
işaretleyici
(00 00)
blok şifreleme anahtarı uzunluğu
(00 00 00 18)
blok şifreleme blok boyutu
(00 00 00 10)
HMAC anahtar uzunluğu
(00 00 00 20)
HMAC özet boyutu
(00 00 00 20)
blok şifreleme PRP çıkışı
(F4 74 - DB 6F)
veHMAC PRF çıkışı
(D4 79 - end)
.
Dekont
CBC modu şifreleme + HMAC kimlik doğrulaması bağlam üst bilgisi, algoritma uygulamalarının Windows CNG tarafından mı yoksa yönetilen SymmetricAlgorithm ve KeyedHashAlgorithm türleri tarafından mı sağlandığına bakılmaksızın aynı şekilde oluşturulur. Bu, farklı işletim sistemlerinde çalışan uygulamaların, algoritmaların uygulamaları işletim sistemleri arasında farklılık gösterse bile aynı bağlam üst bilgisini güvenilir bir şekilde üretmesini sağlar. (Pratikte KeyedHashAlgorithm'in uygun bir HMAC olması gerekmez. Herhangi bir anahtarlı karma algoritma türü olabilir.)
Örnek: 3DES-192-CBC + HMACSHA1
İlk olarak, belirtilen algoritmalara göre , where | K_E | = 192 bits
ve | K_H | = 160 bits
izin verin( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")
. Bu, aşağıdaki örnekte ve'ye K_E = A219..E2BB
K_H = DC4A..B464
yol açar:
A2 19 60 2F 83 A9 13 EA B0 61 3A 39 B8 A6 7E 22
61 D9 F8 6C 10 51 E2 BB DC 4A 00 D7 03 A2 48 3E
D1 F7 5A 34 EB 28 3E D7 D4 67 B4 64
Ardından, yukarıda gösterildiği gibi ve verilen IV = 0*
K_E
3DES-192-CBC için işlemEnc_CBC (K_E, IV, "")
.
result := ABB100F81E53E10E
Ardından, yukarıdaki gibi verilen K_H
HMACSHA1 için işlem MAC(K_H, "")
yapın.
result := 76EB189B35CF03461DDF877CD9F4B1B4D63A7555
Bu, aşağıda gösterilen kimliği doğrulanmış şifreleme algoritması çiftinin (3DES-192-CBC şifreleme + HMACSHA1 doğrulama) parmak izi olan tam bağlam üst bilgisini oluşturur:
00 00 00 00 00 18 00 00 00 08 00 00 00 14 00 00
00 14 AB B1 00 F8 1E 53 E1 0E 76 EB 18 9B 35 CF
03 46 1D DF 87 7C D9 F4 B1 B4 D6 3A 75 55
Bileşenler aşağıdaki gibi ayrılır:
işaretleyici
(00 00)
blok şifreleme anahtarı uzunluğu
(00 00 00 18)
blok şifreleme blok boyutu
(00 00 00 08)
HMAC anahtar uzunluğu
(00 00 00 14)
HMAC özet boyutu
(00 00 00 14)
blok şifreleme PRP çıkışı
(AB B1 - E1 0E)
veHMAC PRF çıkışı
(76 EB - end)
.
Galois/Sayaç Modu şifreleme + kimlik doğrulaması
Bağlam üst bilgisi aşağıdaki bileşenlerden oluşur:
[16 bit] "GCM şifreleme + kimlik doğrulaması" anlamına gelen bir işaretleyici olan 00 01 değeri.
[32 bit] Simetrik blok şifreleme algoritmasının anahtar uzunluğu (bayt cinsinden, büyük endian).
[32 bit] Kimliği doğrulanmış şifreleme işlemleri sırasında kullanılan nonce boyutu (bayt cinsinden büyük endian). (Sistemimiz için bu, nonce boyutu = 96 bit olarak sabittir.)
[32 bit] Simetrik blok şifreleme algoritmasının blok boyutu (bayt cinsinden, büyük endian). (GCM için bu, blok boyutu = 128 bit olarak sabittir.)
[32 bit] Kimliği doğrulanmış şifreleme işlevi tarafından üretilen kimlik doğrulama etiketi boyutu (bayt cinsinden, büyük endian). (Sistemimiz için bu, etiket boyutu = 128 bit olarak düzeltilir.)
[128 bit] etiketi
Enc_GCM (K_E, nonce, "")
, boş bir dize girişi verildiğinde simetrik blok şifreleme algoritmasının çıkışıdır ve burada nonce 96 bit all-zero vektördür.
K_E
CBC şifreleme + HMAC kimlik doğrulama senaryosunda olduğu gibi aynı mekanizma kullanılarak türetilir. Ancak, burada oynanacak bir şey olmadığından K_H
, temelde var | K_H | = 0
ve algoritma aşağıdaki forma daraltılır.
K_E = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")
Örnek: AES-256-GCM
İlk olarak , nerede | K_E | = 256 bits
izin verinK_E = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")
.
K_E := 22BC6F1B171C08C4AE2F27444AF8FC8B3087A90006CAEA91FDCFB47C1B8733B8
Ardından, AES-256-GCM için kimlik doğrulama etiketini Enc_GCM (K_E, nonce, "")
yukarıda gösterildiği nonce = 096
gibi hesapla K_E
.
result := E7DCCE66DF855A323A6BB7BD7A59BE45
Bu, aşağıdaki tam bağlam üst bilgisini oluşturur:
00 01 00 00 00 20 00 00 00 0C 00 00 00 10 00 00
00 10 E7 DC CE 66 DF 85 5A 32 3A 6B B7 BD 7A 59
BE 45
Bileşenler aşağıdaki gibi ayrılır:
işaretleyici
(00 01)
blok şifreleme anahtarı uzunluğu
(00 00 00 20)
nonce boyutu
(00 00 00 0C)
blok şifreleme blok boyutu
(00 00 00 10)
kimlik doğrulama etiketi boyutu
(00 00 00 10)
vekimlik doğrulama etiketinin blok şifrelemesini
(E7 DC - end)
çalıştırmasını sağlar.
ASP.NET Core