Sdílet prostřednictvím

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

  • Článek

Většina klíčů v okruhu klíčů bude obsahovat určitou formu entropie a bude obsahovat algoritmické informace o šifrování CBC a ověřování HMAC nebo GCM encryption + validation. 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 předdefinovaných továren, mechanismus popsaný v této části už neplatí.

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 additionalAuthenticatedData (AAD). Obsah prostého textu beze změny volání IDataProtector.Protect, ale AAD je generován systémem a skládá se ze tří komponent:

  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ězu účelu, který vytvořil IDataProtector tuto operaci.

Vzhledem k tomu, že služba AAD je jedinečná pro řazenou kolekci všech tří komponent, můžeme ji použít k odvození nových klíčů z km místo použití samotného klíče ve všech 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 volá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 = additionalAuthenticatedData

  • context = contextHeader || keyModifier

Hlavička kontextu je proměnlivá délka a v podstatě slouží jako kryptografický otisk algoritmů, pro které 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í.

U operací | K_E | ověřování CBC + HMAC je délka šifrovacího klíče symetrického bloku a | K_H | je velikost hodnoty hash 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 šifrový text se pak provedou rutinou HMAC inicializovanou klíčem K_H k vytvoření mac. Tento proces a návratová hodnota jsou graficky znázorněny níže.

CBC-mode process and return

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

Poznámka

Implementace IDataProtector.Protect předzálohuje hlavičku magic a ID klíče k výstupu před vrácením volajícímu. Protože hlavička magic 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 mac ověřuje každý bajt konečné vrácené datové části.

Šifrování v režimu galois/čítače + ověření

Po K_E vygenerování pomocí výše uvedeného mechanismu vygenerujeme náhodný 96bitový nešifrovaný algoritmus symetrického bloku, který zašifruje prostý text a vytvoří značku 128bitového ověřování.

GCM-mode process and return

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 podporovali flexibilitu, kterou 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 opravíme K_E , nemůžeme provést více než 2^32 operací šifrování před spuštěním afoul limitu 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.