11. Considerazioni sulla sicurezza

11. Considerazioni sulla sicurezza

Ci sono una serie di considerazioni sulla sicurezza che devono essere prese in considerazione dagli implementatori di questa specifica. Le considerazioni sulla sicurezza specifiche per un singolo algoritmo sono posizionate accanto alla descrizione dell'algoritmo. Sebbene alcune considerazioni siano state evidenziate qui, ulteriori considerazioni possono essere trovate nei documenti elencati nei riferimenti.

Le implementazioni devono proteggere il materiale della chiave privata per tutti gli individui. Alcuni casi in questo documento devono essere evidenziati riguardo a questo problema.

• L'uso della stessa chiave per due diversi algoritmi può far trapelare informazioni sulla chiave. Si raccomanda pertanto che le chiavi siano limitate a un singolo algoritmo.

• L'uso di "direct" come algoritmo del destinatario combinato con un secondo algoritmo del destinatario espone la chiave diretta al secondo destinatario; la Sezione 8.5 di [RFC9052] vieta di combinare algoritmi del destinatario "direct" con altre modalità.

• Molti degli algoritmi in questo documento hanno limiti sul numero di volte che una chiave può essere utilizzata senza far trapelare informazioni sulla chiave.

L'uso di ECDH e direct più KDF (senza key wrap) non porterà direttamente alla divulgazione della chiave privata; la funzione unidirezionale del KDF lo impedirà. C'è, tuttavia, un problema diverso che deve essere affrontato. Avere due destinatari richiede che la CEK sia condivisa tra due destinatari. Il secondo destinatario ha quindi una CEK derivata da materiale che può essere utilizzato per la prova debole di origine. Il secondo destinatario potrebbe creare un messaggio utilizzando la stessa CEK e inviarlo al primo destinatario; il primo destinatario, sia per Static-Static ECDH che per direct più KDF, farebbe un'ipotesi che la CEK potrebbe essere utilizzata per la prova di origine, anche se proviene dall'entità sbagliata. Se viene aggiunto il passaggio di key wrap, allora non è implicita alcuna prova di origine e questo non è un problema.

Sebbene sia stato menzionato prima, vale la pena ripetere che l'uso di una singola chiave per più algoritmi è stato dimostrato in alcuni casi far trapelare informazioni su una chiave, fornendo l'opportunità agli aggressori di falsificare i tag di integrità o ottenere informazioni sul contenuto crittografato. Associare una chiave a un singolo algoritmo previene questi problemi. I creatori di chiavi e i consumatori di chiavi sono fortemente incoraggiati non solo a creare nuove chiavi per ogni diverso algoritmo, ma a includere quella selezione di algoritmo in qualsiasi distribuzione di materiale chiave e applicare rigorosamente la corrispondenza degli algoritmi nella struttura della chiave agli algoritmi nella struttura del messaggio. Oltre a verificare che gli algoritmi siano corretti, è necessario verificare anche la forma della chiave. Non utilizzare una chiave "EC2" dove è prevista una chiave "OKP".

Prima di utilizzare una chiave per la trasmissione, o prima di agire sulle informazioni ricevute, è necessario prendere una decisione di fiducia su una chiave. I dati o l'azione sono qualcosa che l'entità associata alla chiave ha il diritto di vedere o il diritto di richiedere? Un numero di fattori è associato a questa decisione di fiducia. Alcuni evidenziati qui sono:

• Quali sono le autorizzazioni associate al proprietario della chiave?

• L'algoritmo crittografico è accettabile nel contesto corrente?

• Le restrizioni associate alla chiave, come l'algoritmo o la freschezza, sono state verificate e sono corrette?

• La richiesta è qualcosa di ragionevole, dato lo stato attuale dell'applicazione?

• Sono state applicate considerazioni sulla sicurezza che fanno parte del messaggio (come specificato dall'applicazione o dal parametro di intestazione "crit")?

C'è un gran numero di algoritmi presentati in questo documento che utilizzano valori nonce. Per tutti i nonce definiti in questo documento, c'è un qualche tipo di restrizione sul fatto che il nonce sia un valore unico per una chiave o altre condizioni. In tutti questi casi, non c'è alcun requisito noto sul fatto che il nonce sia sia unico che imprevedibile; in queste circostanze, è ragionevole utilizzare un contatore per la creazione del nonce. Nei casi in cui si desidera che il modello del nonce sia imprevedibile oltre che unico, si può utilizzare una chiave creata a tale scopo e crittografare il contatore per produrre il valore del nonce.

Un'area che sta ottenendo visibilità è l'analisi del traffico dei messaggi crittografati basata sulla lunghezza del messaggio. Questa specifica non fornisce un metodo uniforme per fornire il padding come parte della struttura del messaggio. Un osservatore può distinguere tra due messaggi diversi (ad esempio, "SÌ" e "NO") in base alla lunghezza per tutti gli algoritmi di crittografia del contenuto definiti in questo documento. Ciò significa che spetta alle applicazioni documentare come deve essere fatto il padding del contenuto al fine di prevenire o scoraggiare tale analisi. (Ad esempio, le stringhe di testo potrebbero essere definite come "SÌ" e "NO ".)

L'analisi fatta in [RFC9147] si basa sul numero di record inviati. Questo dovrebbe mappare bene al numero di messaggi inviati quando si utilizza COSE, quindi quell'analisi dovrebbe valere anche qui, supponendo che i messaggi COSE abbiano all'incirca le stesse dimensioni dei record DTLS. Va notato che i limiti si basano sul numero di messaggi, ma QUIC e DTLS sono sempre endpoint basati su coppie. Al contrario, [OSCORE-GROUPCOMM] utilizza COSE in uno scenario di comunicazione di gruppo. In queste circostanze, potrebbe essere che nessuna singola entità vedrà tutti i messaggi crittografati e quindi nessuna singola entità può attivare l'operazione di rekey.