Appendice A. Linee guida per l'autenticazione dei dati esterni degli algoritmi

Durante lo sviluppo di COSE, il requisito che l'identificatore dell'algoritmo debba trovarsi negli attributi protetti è stato allentato da "deve" a "dovrebbe". Due ragioni fondamentali sono state avanzate per supportare questa posizione. In primo luogo, il messaggio risultante sarà più piccolo se l'identificatore dell'algoritmo viene omesso dai messaggi più comuni in un ambiente CoAP. In secondo luogo, c'è un potenziale bug che sorgerà se il controllo completo non viene eseguito correttamente tra i diversi punti in cui un identificatore dell'algoritmo potrebbe essere posizionato (il messaggio stesso, una dichiarazione dell'applicazione, la struttura della chiave che il mittente possiede e la struttura della chiave che il destinatario possiede).

Questa appendice illustra come tale modifica può essere apportata e i dettagli che un'applicazione deve specificare per utilizzare questa opzione. Vengono specificati due diversi set di dettagli: quelli necessari per omettere un identificatore dell'algoritmo e quelli necessari per utilizzare la variante sull'attributo di controfirma che non contiene attributi su se stesso.

Vengono presentati tre set di raccomandazioni. Il primo set di raccomandazioni si applica all'identificazione di un algoritmo implicito per un singolo livello di un oggetto COSE. Il secondo set di raccomandazioni si applica all'identificazione di più algoritmi impliciti per più livelli di un oggetto COSE. Il terzo set di raccomandazioni si applica all'avere algoritmi impliciti per più costrutti di oggetti COSE.

Le parole chiave di BCP 14 ([RFC2119] e [RFC8174]) non sono deliberatamente utilizzate qui. Questa specifica può fornire raccomandazioni, ma non può applicarle.

Questo set di raccomandazioni si applica al caso in cui un'applicazione sta distribuendo un algoritmo fisso insieme alle informazioni sulla chiave per l'uso in un singolo oggetto COSE. Questo si applica normalmente al più piccolo degli oggetti COSE -- specificamente, COSE_Sign1, COSE_Mac0 e COSE_Encrypt0 -- ma potrebbe applicarsi anche alle altre strutture.

I seguenti elementi dovrebbero essere presi in considerazione:

Le applicazioni devono elencare l'insieme di strutture COSE in cui devono essere utilizzati gli algoritmi impliciti. Le applicazioni devono richiedere che la ricezione di un identificatore di algoritmo esplicito in una di queste strutture porti al rifiuto del messaggio. Questo requisito è dichiarato in modo che non ci sia mai un caso in cui ci sia ambiguità sulla questione di quale algoritmo dovrebbe essere utilizzato, quello implicito o quello esplicito. Questo si applica anche se l'identificatore dell'algoritmo trasportato è un attributo protetto. Questo si applica anche se l'algoritmo trasportato è lo stesso dell'algoritmo implicito.
Le applicazioni devono definire l'insieme di informazioni che deve essere considerato parte di un contesto quando si omettono gli identificatori dell'algoritmo. Come minimo, questo sarebbe l'identificatore della chiave (se necessario), la chiave, l'algoritmo e la struttura COSE con cui viene utilizzato. Le applicazioni dovrebbero limitare l'uso di una singola chiave a un singolo algoritmo. Come notato per alcuni degli algoritmi in [RFC9053], l'uso della stessa chiave in diversi algoritmi correlati può portare alla perdita di informazioni sulla chiave, alla perdita sui dati o alla capacità di eseguire falsificazioni.
In molti casi, le applicazioni che rendono implicito l'identificatore dell'algoritmo vorranno anche rendere implicito l'identificatore del contesto per lo stesso motivo. Cioè, omettere l'identificatore del contesto ridurrà la dimensione del messaggio (potenzialmente in modo significativo, a seconda della lunghezza dell'identificatore). Le applicazioni che fanno questo dovranno descrivere le circostanze in cui l'identificatore del contesto deve essere omesso e come l'identificatore del contesto deve essere dedotto in questi casi. (Una ricerca esaustiva su tutte le chiavi non sarebbe normalmente considerata accettabile.) Un esempio di come ciò può essere fatto è legare il contesto a un identificatore di transazione. Entrambi verrebbero inviati sul messaggio originale, ma solo l'identificatore di transazione dovrebbe essere inviato dopo quel punto, poiché il contesto è legato all'identificatore di transazione. Un altro modo sarebbe associare un contesto a un indirizzo di rete. Tutti i messaggi provenienti da un singolo indirizzo di rete possono essere considerati associati a un contesto specifico. (In questo caso, l'indirizzo verrebbe normalmente distribuito come parte del contesto.)
Le applicazioni non possono fare affidamento sul fatto che gli identificatori delle chiavi siano unici a meno che non compiano sforzi significativi per garantire che siano calcolati in modo tale da creare questa garanzia. Anche quando un'applicazione fa questo, l'unicità potrebbe essere violata se l'applicazione viene eseguita in contesti diversi (cioè, con un fornitore di contesto diverso) o se il sistema combina i contesti di sicurezza di diverse applicazioni insieme in un unico archivio.
Le applicazioni dovrebbero continuare la pratica di proteggere l'identificatore dell'algoritmo. Poiché ciò non viene fatto inserendolo nel campo degli attributi protetti, le applicazioni dovrebbero definire una struttura dati esterna specifica dell'applicazione che includa questo valore. Questo campo dati esterno può essere utilizzato come tale per la crittografia del contenuto, il MAC e gli algoritmi di firma. Può essere utilizzato nel campo SuppPrivInfo per quegli algoritmi che utilizzano una KDF per derivare un valore di chiave. Le applicazioni potrebbero anche voler proteggere altre informazioni che fanno parte della struttura del contesto. Va notato che quei campi, come la chiave o un IV di base, che sono protetti in virtù del loro utilizzo nel calcolo crittografico non devono essere inclusi nel campo dati esterno.

Il secondo caso è avere più identificatori di algoritmo impliciti specificati per un oggetto COSE a più livelli. Un esempio di come funzionerebbe è il contesto di crittografia specificato da un'applicazione, che contiene un algoritmo di crittografia del contenuto, un algoritmo di key wrap, un identificatore di chiave e un segreto condiviso. Il mittente omette l'invio dell'identificatore dell'algoritmo sia per il livello del contenuto che per il livello del destinatario, lasciando solo l'identificatore della chiave. Il ricevitore utilizza quindi l'identificatore della chiave per ottenere gli identificatori dell'algoritmo impliciti.

I seguenti elementi aggiuntivi devono essere presi in considerazione:

Le applicazioni che vogliono supportare questo dovranno definire una struttura che consenta, e identifichi chiaramente, sia la struttura COSE da utilizzare con una data chiave sia la struttura e l'algoritmo da utilizzare per il livello secondario. La chiave per il livello secondario viene calcolata come di consueto dal livello del destinatario.

Il terzo caso è avere più identificatori di algoritmo impliciti, ma mirati a livelli potenzialmente non correlati o diversi oggetti COSE. Esistono diversi scenari in cui questo potrebbe essere applicabile. Alcuni di questi scenari sono:

Due contesti sono distribuiti come coppia. Ciascuno dei contesti è per l'uso con un messaggio COSE_Encrypt. Ogni contesto sarà costituito da chiavi segrete e IV distinti e potenzialmente anche algoritmi diversi. Un contesto è per l'invio di messaggi dalla parte A alla parte B, e il secondo contesto è per l'invio di messaggi dalla parte B alla parte A. Ciò significa che non c'è possibilità che si verifichi un attacco di riflessione, poiché ogni parte utilizza chiavi segrete diverse per inviare i suoi messaggi; un messaggio che viene riflesso a essa non riuscirebbe a essere decifrato.
Due contesti sono distribuiti come coppia. Il primo contesto viene utilizzato per la crittografia del messaggio e il secondo contesto viene utilizzato per posizionare una controfirma sul messaggio. L'intenzione è che il secondo contesto possa essere distribuito ad altre entità indipendentemente dal primo contesto. Ciò consente a queste entità di convalidare che il messaggio proveniva da un individuo senza essere in grado di decifrare il messaggio e vedere il contenuto.
Due contesti sono distribuiti come coppia. Il primo contesto contiene una chiave per gestire i messaggi con MAC, e il secondo contesto contiene una chiave diversa per gestire i messaggi crittografati. Ciò consente una distribuzione unificata delle chiavi ai partecipanti per diversi tipi di messaggi che hanno chiavi diverse, ma dove le chiavi possono essere utilizzate in modo coordinato.

Per questi casi, devono essere considerati i seguenti elementi aggiuntivi:

Le applicazioni devono garantire che i contesti multipli rimangano associati. Se uno dei contesti viene invalidato per qualsiasi motivo, anche tutti i contesti associati ad esso dovrebbero essere invalidati.