Sdílet prostřednictvím

Kontextová záhlaví v ASP.NET Core

Pozadí a teorie

V systému ochrany dat "klíč" znamená objekt, který může poskytovat ověřené šifrovací služby. Každý klíč je identifikován jedinečným ID (GUID) a nese s ním algoritmické informace a entropický materiál. Je zamýšleno, že každý klíč má jedinečnou entropii, ale systém to nemůže vynutit, a musíme také počítat s vývojáři, kteří můžou změnit okruh klíčů ručně úpravou algoritmických informací existujícího klíče v okruhu klíčů. Abychom dosáhli bezpečnostních požadavků v těchto případech, systém ochrany dat má koncept kryptografické flexibility, která umožňuje bezpečně používat jednu entropickou hodnotu napříč několika kryptografickými algoritmy.

Většina systémů, které podporují kryptografickou flexibilitu, tak, že do datové části zahrne některé identifikační informace o algoritmu. Identifikátor OID algoritmu je obecně dobrým kandidátem. Jedním z problémů, na který jsme narazili, je, že existují různé způsoby, jak určit stejný algoritmus: "AES" (CNG) a spravované třídy Aes, AesManaged, AesCryptoServiceProvider, AesCng a RijndaelManaged (vzhledem ke konkrétním parametrům) jsou ve skutečnosti stejné a musíme zachovat mapování všech těchto tříd na správný identifikátor OID. Pokud by vývojář chtěl poskytnout vlastní algoritmus (nebo dokonce jinou implementaci AES!), museli by nám sdělit jeho identifikátor OID. Díky tomuto dodatečnému kroku registrace je konfigurace systému obzvláště bolestivá.

Když jsme se zamysleli, rozhodli jsme se, že k problému přistupujeme ze špatné strany. Identifikátor OID vám řekne, co je algoritmus, ale ve skutečnosti nás to nezajímá. Pokud potřebujeme bezpečně použít jednu entropickou hodnotu ve dvou různých algoritmech, není nutné vědět, co jsou algoritmy skutečně. Záleží nám na tom, jak se chovají. Jakýkoli slušný symetrický blokový šifrovací algoritmus je také silná pseudonáhodná permutace (PRP): nastavte vstupy (klíč, režim řetězení, IV, plaintext) a výstup šifry bude s vysokou pravděpodobností odlišný od jakéhokoli jiného symetrického blokového šifrovacího algoritmu při použití stejných vstupů. Podobně každá slušná klíčová hashovací funkce je také silná pseudonáhodná funkce (PRF) a vzhledem k pevné vstupní sadě bude její výstup výrazně odlišný od jakékoli jiné klíčové hashovací funkce.

Tento koncept silných PRP a PRF používáme k vytvoření hlavičky kontextu. Tato hlavička kontextu v podstatě funguje jako stabilní kryptografický otisk nad algoritmy, které se používají pro jakoukoli danou operaci, a poskytuje kryptografickou flexibilitu potřebnou systémem ochrany dat. Tato hlavička je reprodukovatelná a později se použije jako součást procesu odvození podklíče. Existují dva různé způsoby, jak vytvořit hlavičku kontextu v závislosti na režimech provozu podkladových algoritmů.

Šifrování v režimu CBC + ověřování HMAC

Záhlaví kontextu se skládá z následujících komponent:

  • [16 bitů] Hodnota 00 00, což je značka označující "šifrování CBC + ověřování HMAC".

  • [32 bitů] Délka klíče (v bajtech, big-endian) symetrického blokového šifrovacího algoritmu.

  • [32 bitů] Velikost bloku (v bajtech, big-endian) symetrického blokového šifrovacího algoritmu.

  • [32 bitů] Délka klíče (v bajtech, big-endian) algoritmu HMAC. (V současné době se velikost klíče vždy shoduje s velikostí otisku.)

  • [32 bitů] Velikost hodnot hash (v bajtech, big-endian) algoritmu HMAC.

  • EncCBC(K_E, IV, ""), což je výstup symetrického blokového šifrovacího algoritmu při zadání prázdného řetězce, kde IV je vektor samých nul. Konstrukce K_E je popsána níže.

  • MAC(K_H, ""), což je výstup algoritmu HMAC zadaný prázdným řetězcovým vstupem. Konstrukce K_H je popsána níže.

V ideálním případě bychom mohli předat vektory samých nul pro K_E a K_H. Chceme se však vyhnout situaci, kdy základní algoritmus před provedením jakýchkoli operací (zejména DES a 3DES) kontroluje existenci slabých klíčů, což brání použití jednoduchého nebo opakovatelného vzoru jako all-zero vektor.

Místo toho použijeme NIST SP800-108 KDF v režimu čítače (viz NIST SP800-108, s. 5.1) s klíčem nulové délky, popiskem a kontextem a HMACSHA512 jako podkladovou PRF. Odvodíme | K_E | + | K_H | bajtů výstupu a poté výsledek rozložíme na K_E a K_H samotné. Matematicky je to reprezentováno následujícím způsobem.

( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")

Příklad: AES-192-CBC + HMACSHA256

Představte si například případ, kdy algoritmus symetrického blokového šifrování je AES-192-CBC a ověřovací algoritmus je HMACSHA256. Systém vygeneruje hlavičku kontextu pomocí následujícího postupu.

Nejprve přiřaďte ( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = ""), kde | K_E | = 192 bits a | K_H | = 256 bits podle specifikovaných algoritmů. To vede ke K_E = 5BB6..21DD a K_H = A04A..00A9 v příkladu níže:

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

Dále spočítejte Enc_CBC (K_E, IV, "") pro AES-192-CBC s použitím IV = 0* a K_E, jak je uvedeno výše.

result := F474B1872B3B53E4721DE19C0841DB6F

Dále vypočítejte MAC(K_H, "") pro HMACSHA256 vzhledem k K_H uvedenému výše.

result := D4791184B996092EE1202F36E8608FA8FBD98ABDFF5402F264B1D7211536220C

Výsledkem je následující úplná hlavička kontextu:

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

Toto záhlaví kontextu je kryptografický otisk dvojice ověřených šifrovacích algoritmů (šifrování AES-192-CBC + ověření HMACSHA256). Komponenty, jak je popsáno výše , jsou:

  • značka (00 00)

  • délka šifrovacího klíče bloku (00 00 00 18)

  • velikost bloku bloku šifry (00 00 00 10)

  • délka klíče HMAC (00 00 00 20)

  • velikost otisku HMAC (00 00 00 20)

  • Výstup PRP blokové šifry (F4 74 - DB 6F) a

  • výstup HMAC PRF (D4 79 - end).

Poznámka:

Šifrování v režimu CBC a hlavička kontextu ověřování HMAC jsou sestaveny stejným způsobem bez ohledu na to, zda jsou implementace algoritmů realizovány systémem Windows CNG, nebo spravovanými typy SymmetricAlgorithm a KeyedHashAlgorithm. To umožňuje aplikacím běžícím v různých operačních systémech spolehlivě vytvořit stejnou hlavičku kontextu, i když se implementace algoritmů mezi operačními systémy liší. (V praxi nemusí keyedHashAlgorithm být správný HMAC. Může se jednat o libovolný typ algoritmu hash s klíči.)

Příklad: 3DES-192-CBC + HMACSHA1

Nejprve přiřaďte ( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = ""), kde | K_E | = 192 bits a | K_H | = 160 bits podle specifikovaných algoritmů. To vede ke K_E = A219..E2BB a K_H = DC4A..B464 v příkladu níže:

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

Dále vypočítejte Enc_CBC (K_E, IV, "") pro 3DES-192-CBC vzhledem k IV = 0* a K_E, jak je uvedeno výše.

result := ABB100F81E53E10E

Dále vypočítejte MAC(K_H, "") pro HMACSHA1 s ohledem na K_H výše uvedené.

result := 76EB189B35CF03461DDF877CD9F4B1B4D63A7555

Tím se vytvoří úplná hlavička kontextu, což je kryptografický otisk dvojice ověřených šifrovacích algoritmů (šifrování 3DES-192-CBC + ověření HMACSHA1), jak je znázorněno níže:

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

Komponenty se rozdělí takto:

  • značka (00 00)

  • délka šifrovacího klíče bloku (00 00 00 18)

  • velikost bloku bloku šifry (00 00 00 08)

  • délka klíče HMAC (00 00 00 14)

  • velikost hodnoty hash HMAC (00 00 00 14)

  • výstup blokové šifry PRP a

  • výstup HMAC PRF (76 EB - end).

Šifrování Galois/čítací režim + ověřování

Záhlaví kontextu se skládá z následujících komponent:

  • [16 bitů] Hodnota 00 01, což je značka označující "šifrování GCM + ověřování".

  • [32 bitů] Délka klíče (v bajtech, big-endian) symetrického blokového šifrovacího algoritmu.

  • [32 bitů] Velikost nonce (v bajtech, big-endian) použitá během ověřených operací šifrování. (V našem systému je hodnota nonce pevně nastavena na velikost 96 bitů.)

  • [32 bitů] Velikost bloku (v bajtech, big-endian) symetrického blokového šifrovacího algoritmu. (U GCM je to pevné při velikosti bloku = 128 bitů.)

  • [32 bitů] Velikost ověřovací značky (v bajtech, big-endian) vytvořená ověřenou šifrovací funkcí. (V našem systému je to pevně nastaveno na velikost značky = 128 bitů.)

  • [128 bitů] Značka Enc_GCM (K_E, nonce, ""), která je výstupem symetrického blokového šifrovacího algoritmu při zadání prázdného řetězce a kde nonce je 96bitový vektor samých nul.

K_E je odvozen pomocí stejného mechanismu jako ve scénáři ověřování CBC + HMAC. Jelikož zde není přítomno K_H, v zásadě máme | K_H | = 0, a algoritmus se zjednoduší do níže uvedené formy.

K_E = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")

Příklad: AES-256-GCM

Nejprve definujte K_E = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = ""), kde | K_E | = 256 bits.

K_E := 22BC6F1B171C08C4AE2F27444AF8FC8B3087A90006CAEA91FDCFB47C1B8733B8

Dále vypočítejte ověřovací značku Enc_GCM (K_E, nonce, "") pro AES-256-GCM, přičemž je dána nonce = 096 a K_E výše uvedenými.

result := E7DCCE66DF855A323A6BB7BD7A59BE45

Výsledkem je následující úplná hlavička kontextu:

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

Komponenty se rozdělí takto:

  • značka (00 01)

  • délka šifrovacího klíče bloku (00 00 00 20)

  • velikost nonce (00 00 00 0C)

  • velikost blokové šifry (00 00 00 10)

  • velikost (00 00 00 10) značky ověřování a

  • ověřovací značka ze spuštění blokové šifry (E7 DC - end).

  • Last updated on