3. Notes to HKDF Users (Note per gli utenti di HKDF)

Questa sezione contiene una serie di principi guida riguardanti l'uso di HKDF. Un resoconto molto più esteso di tali principi e della logica di progettazione può essere trovato in [HKDF-paper].

3.1. To Salt or not to Salt (Utilizzare o meno il salt)

HKDF è definito per funzionare con e senza salt casuale. Questo viene fatto per adattarsi ad applicazioni in cui un valore salt non è disponibile. Sottolineiamo tuttavia che l'uso del salt aggiunge significativamente alla forza di HKDF, garantendo l'indipendenza tra diversi usi della funzione hash, supportando l'estrazione "indipendente dalla sorgente" e rafforzando i risultati analitici che supportano il design di HKDF.

Il salt casuale differisce fondamentalmente dal materiale di chiave iniziale in due modi: è non segreto e può essere riutilizzato. Come tale, i valori salt sono disponibili per molte applicazioni. Ad esempio, un generatore di numeri pseudocasuali (PRNG) che produce continuamente output applicando HKDF a pool di entropia rinnovabili (ad esempio, eventi di sistema campionati) può fissare un valore salt e utilizzarlo per più applicazioni di HKDF senza dover proteggere la segretezza del salt. In un diverso dominio applicativo, un protocollo di accordo di chiavi che deriva chiavi crittografiche da uno scambio Diffie-Hellman può derivare un valore salt da nonce pubblici scambiati e autenticati tra le parti comunicanti come parte dell'accordo di chiavi (questo è l'approccio adottato in [IKEv2]).

Idealmente, il valore salt è una stringa casuale (o pseudocasuale) di lunghezza HashLen. Tuttavia, anche un valore salt di qualità inferiore (più corto o con entropia limitata) può ancora dare un contributo significativo alla sicurezza del materiale di chiave di output; i progettisti di applicazioni sono quindi incoraggiati a fornire valori salt a HKDF se tali valori possono essere ottenuti dall'applicazione.

Vale la pena notare che, sebbene non sia il caso tipico, alcune applicazioni possono anche avere un valore salt segreto disponibile per l'uso; in tal caso, HKDF fornisce una garanzia di sicurezza ancora più forte. Un esempio di tale applicazione è IKEv1 nella sua "modalità di crittografia a chiave pubblica", dove il "salt" per l'estrattore è calcolato da nonce che sono segreti; analogamente, la modalità pre-condivisa di IKEv1 utilizza un salt segreto derivato dalla chiave pre-condivisa.

3.2. The 'info' Input to HKDF (L'input 'info' per HKDF)

Sebbene il valore 'info' sia opzionale nella definizione di HKDF, è spesso di grande importanza nelle applicazioni. Il suo obiettivo principale è legare il materiale di chiave derivato a informazioni specifiche dell'applicazione e del contesto. Ad esempio, 'info' può contenere un numero di protocollo, identificatori di algoritmo, identità utente, ecc. In particolare, può impedire la derivazione dello stesso materiale di chiave per contesti diversi (quando lo stesso materiale di chiave di input (IKM) è utilizzato in tali contesti diversi). Può anche accogliere input aggiuntivi alla parte di espansione della chiave, se desiderato (ad esempio, un'applicazione potrebbe voler legare il materiale di chiave alla sua lunghezza L, rendendo così L parte del campo 'info'). C'è un requisito tecnico per 'info': dovrebbe essere indipendente dal valore del materiale di chiave di input IKM.

3.3. To Skip or not to Skip (Saltare o non saltare)

In alcune applicazioni, il materiale di chiave di input IKM può già essere presente come chiave crittograficamente forte (ad esempio, il segreto preliminare nelle suite di cifratura TLS RSA sarebbe una stringa pseudocasuale, eccetto per i primi due ottetti). In questo caso, si può saltare la parte di estrazione e utilizzare IKM direttamente per chiavare HMAC nel passo di espansione. D'altra parte, le applicazioni possono ancora utilizzare la parte di estrazione per motivi di compatibilità con il caso generale. In particolare, se IKM è casuale (o pseudocasuale) ma più lungo di una chiave HMAC, il passo di estrazione può servire per produrre una chiave HMAC appropriata (nel caso di HMAC questo accorciamento tramite l'estrattore non è strettamente necessario poiché HMAC è definito per funzionare anche con chiavi lunghe). Si noti tuttavia che se l'IKM è un valore Diffie-Hellman, come nel caso di TLS con Diffie-Hellman, allora la parte di estrazione NON DOVREBBE essere saltata. Farlo risulterebbe nell'uso del valore Diffie-Hellman g^{xy} stesso (che NON è una stringa uniformemente casuale o pseudocasuale) come chiave PRK per HMAC. Invece, HKDF dovrebbe applicare il passo di estrazione a g^{xy} (preferibilmente con un valore salt) e utilizzare il PRK risultante come chiave per HMAC nella parte di espansione.

Nel caso in cui la quantità di bit di chiave richiesti, L, non sia superiore a HashLen, si potrebbe utilizzare PRK direttamente come OKM. Questo, tuttavia, NON è RACCOMANDATO, specialmente perché ometterebbe l'uso di 'info' come parte del processo di derivazione (e aggiungere 'info' come input al passo di estrazione non è consigliabile -- vedere [HKDF-paper]).

3.4. The Role of Independence (Il ruolo dell'indipendenza)

L'analisi delle funzioni di derivazione chiavi presume che il materiale di chiave di input (IKM) provenga da una fonte modellata come distribuzione di probabilità su flussi di bit di una certa lunghezza (ad esempio, flussi prodotti da un pool di entropia, valori derivati da esponenti Diffie-Hellman scelti casualmente, ecc.); ogni istanza di IKM è un campione da quella distribuzione. Un obiettivo principale delle funzioni di derivazione chiavi è garantire che, quando si applica la KDF a due valori qualsiasi IKM e IKM' campionati dalla (stessa) distribuzione sorgente, le chiavi risultanti OKM e OKM' siano essenzialmente indipendenti l'una dall'altra (in senso statistico o computazionale). Per raggiungere questo obiettivo, è importante che gli input alla KDF siano selezionati da distribuzioni di input appropriate e anche che gli input siano scelti indipendentemente l'uno dall'altro (tecnicamente, è necessario che ogni campione abbia entropia sufficiente, anche quando condizionato su altri input alla KDF).

L'indipendenza è anche un aspetto importante del valore salt fornito a una KDF. Sebbene non sia necessario mantenere segreto il salt, e lo stesso valore salt possa essere utilizzato con più valori IKM, si presume che i valori salt siano indipendenti dal materiale di chiave di input. In particolare, un'applicazione deve assicurarsi che i valori salt non siano scelti o manipolati da un attaccante. Come esempio, consideriamo il caso (come in IKE) in cui il salt è derivato da nonce forniti dalle parti in un protocollo di scambio chiavi. Prima che il protocollo possa utilizzare tale salt per derivare chiavi, deve assicurarsi che questi nonce siano autenticati come provenienti dalle parti legittime piuttosto che selezionati dall'attaccante (in IKE, ad esempio, questa autenticazione è parte integrante dello scambio Diffie-Hellman autenticato).