Odvození podklíče a ověřené šifrování v ASP.NET Core

Většina klíčů ve svazku klíčů bude obsahovat určitou formu entropie a bude mít algoritmické informace uvádějící "šifrování CBC + ověřování HMAC" nebo "šifrování GCM + ověřování". V těchto případech označujeme vloženou entropii jako hlavní klíč (nebo KM) pro tento klíč a provedeme funkci odvození klíče, která odvozuje klíče, které se použijí pro skutečné kryptografické operace.

Poznámka:

Klíče jsou abstraktní a vlastní implementace se nemusí chovat jako níže. Pokud klíč poskytuje vlastní implementaci IAuthenticatedEncryptor namísto použití některé z našich vestavěných továren, mechanismus popsaný v této části se již neuplatňuje.

Další ověřená data a odvození podklíče

Rozhraní IAuthenticatedEncryptor slouží jako základní rozhraní pro všechny ověřené operace šifrování. Jeho Encrypt metoda přebírá dvě vyrovnávací paměti: prostý text a dodatečně autentizovaná data (AAD). Obsah prostého textu proudí beze změny do volání IDataProtector.Protect, ale AAD je generován systémem a skládá se ze tří složek.

1. 32bitová hlavička magic 09 F0 C9 F0, která identifikuje tuto verzi systému ochrany dat.

2. 128bitové ID klíče.

3. Řetězec s proměnnou délkou vytvořený z řetězce účelu, který vytvořil IDataProtector a provádí tuto operaci.

Vzhledem k tomu, že AAD je jedinečná pro uspořádanou trojici všech tří komponent, můžeme ji použít k odvození nových klíčů z KM namísto použití KM samotného ve všech našich kryptografických operacích. Pro každé volání IAuthenticatedEncryptor.Encryptprobíhá následující proces odvození klíče:

( K_E, K_H ) = SP800_108_CTR_HMACSHA512(K_M, AAD, contextHeader || keyModifier)

Tady používáme NIST SP800-108 KDF v režimu čítače (viz NIST SP800-108, s. 5.1) s následujícími parametry:

• Klíč odvození klíče (KDK) = K_M

• PRF = HMACSHA512

• label = dodatečněOvěřenáData

• context = contextHeader || keyModifier

Hlavička kontextu je proměnné délky a v zásadě slouží jako otisk algoritmů, ze kterých odvozujeme K_E a K_H. Modifikátor klíče je 128bitový řetězec náhodně vygenerovaný pro každé volání Encrypt a slouží k zajištění obrovské pravděpodobnosti, že KE a KH jsou jedinečné pro tuto konkrétní operaci šifrování ověřování, i když je všechny ostatní vstupy do KDF konstantní.

Pro operace šifrování v CBC režimu + ověřování HMAC je délka šifrovacího klíče symetrického bloku | K_E |, a | K_H | je velikost výstupu rutiny HMAC. Pro operace šifrování GCM + ověřování, | K_H | = 0.

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

Jakmile K_E se vygeneruje pomocí výše uvedeného mechanismu, vygenerujeme vektor náhodné inicializace a spustíme algoritmus symetrického blokového šifrování k šifrování prostého textu. Inicializační vektor a šifrovaný text se pak zpracují rutinou HMAC inicializovanou klíčem K_H k vytvoření MAC. Tento proces a návratová hodnota jsou graficky znázorněny níže.

output:= keyModifier || iv || E_cbc (K_E,iv,data) || HMAC(K_H, iv || E_cbc (K_E,iv,data))

Poznámka:

Implementace IDataProtector.Protectpředřadí magickou hlavičku a identifikátor klíče k výstupu před vrácením volajícímu. Protože magická hlavička a ID klíče jsou implicitně součástí AAD a protože modifikátor klíče je předán jako vstup do KDF, znamená to, že každý bajt výsledných vrácených užitkových dat je autentizován pomocí MAC.

Šifrování v režimu Galois/Čítač + ověřování

Po vygenerování K_E pomocí výše uvedeného mechanismu vygenerujeme náhodný 96bitový jednorázový řetězec a poté spustíme algoritmus symetrického bloku pro zašifrování prostého textu a vytvoření 128bitové autentizační značky.

output := keyModifier || nonce || E_gcm (K_E,nonce,data) || authTag

Poznámka:

I když GCM nativně podporuje koncept AAD, stále dodáváme AAD pouze do původního KDF a rozhodli jsme se předat prázdný řetězec do GCM pro jeho parametr AAD. Důvod, proč je to dvounásobný. Za prvé, abychom podpořili agilitu, nikdy nechceme používat K_M přímo jako šifrovací klíč. GCM navíc na vstupy ukládá velmi přísné požadavky na jedinečnost. Pravděpodobnost, že se šifrovací rutina GCM někdy vyvolá na dvou nebo více odlišných sadách vstupních dat se stejným párem (klíč, nece), nesmí překročit 2^-32. Pokud stanovíme K_E, nemůžeme provést více než 2^32 operací šifrování, aniž bychom překročili limit 2^-32. Může to vypadat jako velmi velký počet operací, ale webový server s vysokým provozem může během pouhých dnů procházet 4 miliardy požadavků, a to během normální životnosti těchto klíčů. Abychom zůstali v souladu s limitem pravděpodobnosti 2^-32, budeme nadále používat modifikátor 128bitového klíče a 96bitovou nece, což výrazně rozšiřuje využitelný počet operací pro všechny dané K_M. Kvůli jednoduchosti návrhu sdílíme cestu kódu KDF mezi operacemi CBC a GCM a vzhledem k tomu, že AAD je už v KDF považována za rutinu GCM, není nutné ji předávat rutině GCM.