4. Algoritmi di Crittografia del Contenuto
- Algoritmi di Crittografia del Contenuto
La Sezione 8.3 di [RFC9052] contiene una descrizione generica degli algoritmi di crittografia del contenuto. Questo documento definisce l'identificatore e gli usi per tre algoritmi di crittografia del contenuto.
4.1. AES-GCM
La modalità Galois/Counter Mode (GCM) è una modalità di cifrario a blocchi AEAD generica definita in [AES-GCM]. La modalità GCM è combinata con l'algoritmo di crittografia a blocchi AES per definire un cifrario AEAD.
La modalità GCM è parametrizzata dalla dimensione del tag di autenticazione e dalla dimensione del nonce. Questo documento fissa la dimensione del nonce a 96 bit. La dimensione del tag di autenticazione è limitata a un piccolo insieme di valori. Per questo documento, tuttavia, la dimensione del tag di autenticazione è fissata a 128 bit.
L'insieme di algoritmi definiti in questo documento si trova nella Tabella 5.
+=========+=======+==========================================+
| Nome | Valore| Descrizione |
+=========+=======+==========================================+
| A128GCM | 1 | Modalità AES-GCM con chiave a 128 bit, |
| | | tag a 128 bit |
+---------+-------+------------------------------------------+
| A192GCM | 2 | Modalità AES-GCM con chiave a 192 bit, |
| | | tag a 128 bit |
+---------+-------+------------------------------------------+
| A256GCM | 3 | Modalità AES-GCM con chiave a 256 bit, |
| | | tag a 128 bit |
+---------+-------+------------------------------------------+
Tabella 5: Valori dell'Algoritmo per AES-GCM
Le chiavi possono essere ottenute da una struttura di chiave o da una struttura del destinatario. Le implementazioni che stanno crittografando o decrittografando DEVONO convalidare che il tipo di chiave, la lunghezza della chiave e l'algoritmo siano corretti e appropriati per le entità coinvolte.
Quando si utilizza una chiave COSE per questo algoritmo, vengono effettuati i seguenti controlli:
-
Il campo "kty" DEVE essere presente, e DEVE essere "Symmetric".
-
Se il campo "alg" è presente, DEVE corrispondere all'algoritmo AES-GCM utilizzato.
-
Se il campo "key_ops" è presente, DEVE includere "encrypt" o "wrap key" durante la crittografia.
-
Se il campo "key_ops" è presente, DEVE includere "decrypt" o "unwrap key" durante la decrittografia.
4.1.1. Considerazioni sulla Sicurezza per AES-GCM
Quando si utilizza AES-GCM, le seguenti restrizioni DEVONO essere applicate:
-
La coppia chiave e nonce DEVE essere unica per ogni messaggio crittografato.
-
Il numero totale di messaggi crittografati per una singola chiave NON DEVE superare 2^32 [SP800-38D]. Un controllo esplicito è richiesto solo in ambienti in cui si prevede che questo limite possa essere superato.
-
[RFC8446] contiene un'analisi sull'uso di AES-CGM per il suo ambiente. Sulla base di tale raccomandazione, si dovrebbe limitare il numero di messaggi crittografati a 2^24.5.
-
Un'analisi più recente in [ROBUST] indica che il numero di decrittografie fallite deve essere preso in considerazione come parte della determinazione di quando deve essere effettuato un rollover della chiave. Seguendo la raccomandazione in DTLS (Sezione 4.5.3 di [RFC9147]), il numero di decrittografie di messaggi fallite dovrebbe essere limitato a 2^36.
È stata presa in considerazione la possibilità di supportare valori di tag più piccoli; la comunità vincolata desidererebbe dimensioni dei tag nell'intervallo di 64 bit. Tale uso cambia drasticamente sia la dimensione massima del messaggio (generalmente non un problema) sia il numero di volte che una chiave può essere utilizzata. Dato che Counter with CBC-MAC (CCM) è la modalità abituale per gli ambienti vincolati, le modalità limitate non sono supportate.
4.2. AES-CCM
CCM è una modalità di cifrario a blocchi di crittografia con autenticazione generica definita in [RFC3610]. La modalità CCM è combinata con l'algoritmo di crittografia a blocchi AES per definire un cifrario AEAD comunemente usato nei dispositivi vincolati.
La modalità CCM ha due scelte di parametri. La prima scelta è M, la dimensione del campo di autenticazione. La scelta del valore per M comporta un compromesso tra la crescita del messaggio (dal tag) e la probabilità che un attaccante possa modificare un messaggio in modo non rilevabile. La seconda scelta è L, la dimensione del campo lunghezza. Questo valore richiede un compromesso tra la dimensione massima del messaggio e la dimensione del nonce.
È sfortunato che la specifica per CCM abbia specificato L ed M come un conteggio di byte piuttosto che un conteggio di bit. Ciò porta a possibili malintesi in cui AES-CCM-8 viene spesso utilizzato per riferirsi a una versione della modalità CCM in cui la dimensione dell'autenticazione è di 64 bit e non 8 bit. Nella maggior parte delle specifiche degli algoritmi crittografici, questi valori sono stati tradizionalmente specificati come conteggi di bit piuttosto che conteggi di byte. Questo documento seguirà la convenzione di utilizzare i conteggi di bit in modo che sia più facile confrontare i diversi algoritmi presentati in questo documento.
Definiamo una matrice di algoritmi in questo documento sui valori di L ed M. I dispositivi vincolati operano solitamente in situazioni in cui utilizzano messaggi brevi e vogliono evitare di eseguire operazioni crittografiche specifiche del destinatario. Ciò favorisce valori più piccoli di L ed M. I dispositivi meno vincolati vorranno essere in grado di utilizzare messaggi più grandi e sono più disposti a generare nuove chiavi per ogni operazione. Ciò favorisce valori più grandi di L ed M.
Vengono utilizzati i seguenti valori per L:
16 bit (2): Questo limita i messaggi a 2^16 byte (64 KiB) di lunghezza. Questo è sufficientemente lungo per i messaggi nel mondo vincolato. La lunghezza del nonce è di 13 byte consentendo 2^104 possibili valori del nonce senza ripetizioni.
64 bit (8): Questo limita i messaggi a 2^64 byte di lunghezza. La lunghezza del nonce è di 7 byte, consentendo 2^56 possibili valori del nonce senza ripetizioni.
Vengono utilizzati i seguenti valori per M:
64 bit (8): Questo produce un tag di autenticazione a 64 bit. Ciò implica che c'è una possibilità su 2^64 che un messaggio modificato venga autenticato.
128 bit (16): Questo produce un tag di autenticazione a 128 bit. Ciò implica che c'è una possibilità su 2^128 che un messaggio modificato venga autenticato.
+====================+=======+====+=====+========+===============+
| Nome | Valore| L | M | Lung. | Descrizione |
| | | | | Chiave | |
+====================+=======+====+=====+========+===============+
| AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | Modalità AES- |
| | | | | | CCM chiave |
| | | | | | 128 bit, tag |
| | | | | | 64 bit, nonce |
| | | | | | 13 byte |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | Modalità AES- |
| | | | | | CCM chiave |
| | | | | | 256 bit, tag |
| | | | | | 64 bit, nonce |
| | | | | | 13 byte |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | Modalità AES- |
| | | | | | CCM chiave |
| | | | | | 128 bit, tag |
| | | | | | 64 bit, nonce |
| | | | | | 7 byte |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | Modalità AES- |
| | | | | | CCM chiave |
| | | | | | 256 bit, tag |
| | | | | | 64 bit, nonce |
| | | | | | 7 byte |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | Modalità AES- |
| | | | | | CCM chiave |
| | | | | | 128 bit, tag |
| | | | | | 128 bit, |
| | | | | | nonce 13 byte |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | Modalità AES- |
| | | | | | CCM chiave |
| | | | | | 256 bit, tag |
| | | | | | 128 bit, |
| | | | | | nonce 13 byte |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | Modalità AES- |
| | | | | | CCM chiave |
| | | | | | 128 bit, tag |
| | | | | | 128 bit, |
| | | | | | nonce 7 byte |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | Modalità AES- |
| | | | | | CCM chiave |
| | | | | | 256 bit, tag |
| | | | | | 128 bit, |
| | | | | | nonce 7 byte |
+--------------------+-------+----+-----+--------+---------------+
Tabella 6: Valori dell'Algoritmo per AES-CCM
Le chiavi possono essere ottenute da una struttura di chiave o da una struttura del destinatario. Le implementazioni che stanno crittografando o decrittografando DEVONO convalidare che il tipo di chiave, la lunghezza della chiave e l'algoritmo siano corretti e appropriati per le entità coinvolte.
Quando si utilizza una chiave COSE per questo algoritmo, vengono effettuati i seguenti controlli:
-
Il campo "kty" DEVE essere presente, e DEVE essere "Symmetric".
-
Se il campo "alg" è presente, DEVE corrispondere all'algoritmo AES-CCM utilizzato.
-
Se il campo "key_ops" è presente, DEVE includere "encrypt" o "wrap key" durante la crittografia.
-
Se il campo "key_ops" è presente, DEVE includere "decrypt" o "unwrap key" durante la decrittografia.
4.2.1. Considerazioni sulla Sicurezza per AES-CCM
Quando si utilizza AES-CCM, le seguenti restrizioni DEVONO essere applicate:
-
La coppia chiave e nonce DEVE essere unica per ogni messaggio crittografato. Si noti che il valore di L influenza il numero di nonce unici.
-
Il numero totale di volte in cui viene utilizzato il cifrario a blocchi AES NON DEVE superare 2^61 operazioni. Questo limite è la somma delle volte in cui il cifrario a blocchi viene utilizzato nel calcolo del valore MAC ed esecuzione delle operazioni di crittografia del flusso. Un controllo esplicito è richiesto solo in ambienti in cui si prevede che questo limite possa essere superato.
-
[RFC9147] contiene un'analisi sull'uso di AES-CCM per il suo ambiente. Sulla base di tale raccomandazione, si dovrebbe limitare il numero di messaggi crittografati a 2^23.
-
Oltre al numero di messaggi decrittografati con successo, è necessario tracciare anche il numero di decrittografie fallite. Seguendo la raccomandazione in DTLS (Sezione 4.5.3 di [RFC9147]), il numero di decrittografie di messaggi fallite dovrebbe essere limitato a 2^23.5. Se si utilizza il tag a 64 bit, allora i limiti sono significativamente più piccoli se si desidera mantenere gli stessi limiti di integrità. Un protocollo che raccomanda questo deve analizzare quale livello di integrità è accettabile per la dimensione del tag più piccola. Potrebbe essere che, per mantenere il livello di integrità desiderato, sia necessario cambiare chiave ogni 2^7 messaggi.
[RFC3610] richiama inoltre un'altra considerazione degna di nota. È possibile effettuare un attacco di precalcolo contro l'algoritmo nei casi in cui porzioni del testo in chiaro siano altamente prevedibili. Ciò riduce la sicurezza della dimensione della chiave della metà. I modi per affrontare questo attacco includono l'aggiunta di una porzione casuale al valore del nonce e/o l'aumento della dimensione della chiave utilizzata. L'uso di una porzione del nonce per un valore casuale diminuirà il numero di messaggi per i quali una singola chiave può essere utilizzata. Aumentare la dimensione della chiave può richiedere più risorse nel dispositivo vincolato. Vedere le Sezioni 5 e 10 di [RFC3610] per ulteriori informazioni.
4.3. ChaCha20 e Poly1305
ChaCha20 e Poly1305 combinati insieme è una modalità AEAD definita in [RFC8439]. Questo è un algoritmo definito utilizzando un cifrario che non è AES e quindi non soffrirebbe di eventuali debolezze future trovate in AES. Queste funzioni crittografiche sono progettate per essere veloci nelle implementazioni solo software.
La costruzione AEAD ChaCha20/Poly1305 definita in [RFC8439] non ha parametrizzazione. Prende come input una chiave a 256 bit e un nonce a 96 bit, così come il testo in chiaro e dati aggiuntivi, e produce il testo cifrato come output. Definiamo un identificatore di algoritmo per questo algoritmo nella Tabella 7.
+===================+=======+==========================+
| Nome | Valore| Descrizione |
+===================+=======+==========================+
| ChaCha20/Poly1305 | 24 | ChaCha20/Poly1305 con |
| | | chiave 256 bit, tag |
| | | 128 bit |
+-------------------+-------+--------------------------+
Tabella 7: Valore dell'Algoritmo per ChaCha20/Poly1305
Le chiavi possono essere ottenute da una struttura di chiave o da una struttura del destinatario. Le implementazioni che stanno crittografando o decrittografando DEVONO convalidare che il tipo di chiave, la lunghezza della chiave e l'algoritmo siano corretti e appropriati per le entità coinvolte.
Quando si utilizza una chiave COSE per questo algoritmo, vengono effettuati i seguenti controlli:
-
Il campo "kty" DEVE essere presente, e DEVE essere "Symmetric".
-
Se il campo "alg" è presente, DEVE corrispondere all'algoritmo ChaCha20/Poly1305 utilizzato.
-
Se il campo "key_ops" è presente, DEVE includere "encrypt" o "wrap key" durante la crittografia.
-
Se il campo "key_ops" è presente, DEVE includere "decrypt" o "unwrap key" durante la decrittografia.
4.3.1. Considerazioni sulla Sicurezza per ChaCha20/Poly1305
I valori di chiave e nonce DEVONO essere una coppia unica per ogni invocazione dell'algoritmo. I contatori di nonce sono considerati un modo accettabile per garantire che siano unici.
Un'analisi più recente in [ROBUST] indica che il numero di decrittografie fallite deve essere preso in considerazione come parte della determinazione di quando deve essere effettuato un rollover della chiave. Seguendo la raccomandazione in DTLS (Sezione 4.5.3 di [RFC9147]), il numero di decrittografie di messaggi fallite dovrebbe essere limitato a 2^36.
[RFC8446] nota che il numero di sequenza del record (64 bit) si avvolgerebbe prima che il limite di sicurezza sia raggiunto per ChaCha20/Poly1305. Le implementazioni COSE non dovrebbero inviare più di 2^64 messaggi crittografati utilizzando una singola chiave ChaCha20/Poly1305.