12. Considerazioni sulla sicurezza

12. Considerazioni sulla sicurezza

Esistono diverse considerazioni sulla sicurezza che devono essere prese in considerazione dagli implementatori di questa specifica. 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 in relazione a questo problema.

• L'uso della stessa chiave per due algoritmi diversi 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 vieta di combinare algoritmi del destinatario "direct" con altre modalità.

• Molti degli algoritmi in [RFC9053] hanno limiti al numero di volte in cui una chiave può essere utilizzata senza far trapelare informazioni sulla chiave.

L'uso di Elliptic Curve Diffie-Hellman (ECDH) e direct plus KDF (senza key wrap) non porterà direttamente alla divulgazione della chiave privata; la funzione unidirezionale della 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 che è stata derivata da materiale che può essere utilizzato per la prova di origine debole. Il secondo destinatario potrebbe creare un messaggio utilizzando la stessa CEK e inviarlo al primo destinatario; il primo destinatario farebbe, sia per ECDH Static-Static che per direct plus KDF, un'ipotesi che la CEK potrebbe essere utilizzata per la prova di origine, anche se proviene dall'entità sbagliata. Se viene aggiunto il passaggio key wrap, 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 per far trapelare informazioni su una chiave, offrendo agli aggressori l'opportunità di falsificare 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 anche a includere tale selezione di algoritmi in qualsiasi distribuzione di materiale chiave e a imporre rigorosamente la corrispondenza degli algoritmi nella struttura della chiave agli algoritmi nella struttura del messaggio. Oltre a verificare che gli algoritmi siano corretti, deve essere verificata 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 certo numero di fattori sono associati a questa decisione di fiducia. Alcuni evidenziati qui sono:

• Quali sono le autorizzazioni associate al proprietario della chiave?

• L'algoritmo crittografico è accettabile nel contesto attuale?

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

• La richiesta è 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")?

Un'area che ha ricevuto visibilità è l'analisi del traffico dei messaggi crittografati in base alla lunghezza del messaggio. Questa specifica non fornisce un metodo uniforme per fornire 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 [RFC9053]. Ciò significa che spetta alle applicazioni documentare come deve essere eseguito 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 ".)