Annexe A. Lignes directrices pour l'authentification des données externes des algorithmes

Au cours du développement de COSE, l'exigence selon laquelle l'identifiant d'algorithme doit être situé dans les attributs protégés a été assouplie de "doit" (must) à "devrait" (should). Deux raisons fondamentales ont été avancées pour soutenir cette position. Premièrement, le message résultant sera plus petit si l'identifiant d'algorithme est omis des messages les plus courants dans un environnement CoAP. Deuxièmement, il existe un bogue potentiel qui surviendra si la vérification complète n'est pas effectuée correctement entre les différents endroits où un identifiant d'algorithme pourrait être placé (le message lui-même, une déclaration d'application, la structure de clé que l'expéditeur possède et la structure de clé que le destinataire possède).

Cette annexe expose comment un tel changement peut être effectué et les détails qu'une application doit spécifier afin d'utiliser cette option. Deux ensembles différents de détails sont spécifiés : ceux nécessaires pour omettre un identifiant d'algorithme et ceux nécessaires pour utiliser la variante de l'attribut de contresignature qui ne contient aucun attribut sur lui-même.

Trois ensembles de recommandations sont présentés. Le premier ensemble de recommandations s'applique à l'identification d'un algorithme implicite pour une seule couche d'un objet COSE. Le deuxième ensemble de recommandations s'applique à l'identification de plusieurs algorithmes implicites pour plusieurs couches d'un objet COSE. Le troisième ensemble de recommandations s'applique à l'existence d'algorithmes implicites pour plusieurs constructions d'objets COSE.

Les mots-clés de BCP 14 ([RFC2119] et [RFC8174]) ne sont délibérément pas utilisés ici. Cette spécification peut fournir des recommandations, mais elle ne peut pas les appliquer.

Cet ensemble de recommandations s'applique au cas où une application distribue un algorithme fixe avec les informations de clé pour une utilisation dans un seul objet COSE. Cela s'applique normalement aux plus petits des objets COSE -- spécifiquement, COSE_Sign1, COSE_Mac0 et COSE_Encrypt0 -- mais pourrait également s'appliquer aux autres structures.

Les éléments suivants devraient être pris en compte :

Les applications doivent lister l'ensemble des structures COSE dans lesquelles les algorithmes implicites doivent être utilisés. Les applications doivent exiger que la réception d'un identifiant d'algorithme explicite dans l'une de ces structures conduise au rejet du message. Cette exigence est énoncée afin qu'il n'y ait jamais de cas où il y ait une ambiguïté sur la question de savoir quel algorithme doit être utilisé, l'implicite ou l'explicite. Cela s'applique même si l'identifiant d'algorithme transporté est un attribut protégé. Cela s'applique même si l'algorithme transporté est le même que l'algorithme implicite.
Les applications doivent définir l'ensemble d'informations qui doivent être considérées comme faisant partie d'un contexte lors de l'omission des identifiants d'algorithme. Au minimum, ce serait l'identifiant de clé (si nécessaire), la clé, l'algorithme et la structure COSE avec laquelle il est utilisé. Les applications devraient restreindre l'utilisation d'une seule clé à un seul algorithme. Comme noté pour certains des algorithmes dans [RFC9053], l'utilisation de la même clé dans différents algorithmes liés peut conduire à une fuite d'informations sur la clé, une fuite sur les données ou la capacité d'effectuer des falsifications.
Dans de nombreux cas, les applications qui rendent l'identifiant d'algorithme implicite voudront également rendre l'identifiant de contexte implicite pour la même raison. C'est-à-dire que l'omission de l'identifiant de contexte réduira la taille du message (potentiellement de manière significative, selon la longueur de l'identifiant). Les applications qui font cela devront décrire les circonstances où l'identifiant de contexte doit être omis et comment l'identifiant de contexte doit être déduit dans ces cas. (Une recherche exhaustive sur toutes les clés ne serait normalement pas considérée comme acceptable.) Un exemple de la façon dont cela peut être fait est de lier le contexte à un identifiant de transaction. Les deux seraient envoyés sur le message original, mais seul l'identifiant de transaction devrait être envoyé après ce point, car le contexte est lié à l'identifiant de transaction. Une autre façon serait d'associer un contexte à une adresse réseau. Tous les messages provenant d'une seule adresse réseau peuvent être supposés être associés à un contexte spécifique. (Dans ce cas, l'adresse serait normalement distribuée dans le cadre du contexte.)
Les applications ne peuvent pas compter sur le fait que les identifiants de clé soient uniques à moins qu'elles ne fassent des efforts importants pour s'assurer qu'ils sont calculés de manière à créer cette garantie. Même lorsqu'une application fait cela, l'unicité pourrait être violée si l'application est exécutée dans différents contextes (c'est-à-dire avec un fournisseur de contexte différent) ou si le système combine les contextes de sécurité de différentes applications ensemble dans un seul magasin.
Les applications devraient continuer la pratique de protéger l'identifiant d'algorithme. Comme cela n'est pas fait en le plaçant dans le champ des attributs protégés, les applications devraient définir une structure de données externe spécifique à l'application qui inclut cette valeur. Ce champ de données externe peut être utilisé tel quel pour le chiffrement de contenu, le MAC et les algorithmes de signature. Il peut être utilisé dans le champ SuppPrivInfo pour les algorithmes qui utilisent une KDF pour dériver une valeur de clé. Les applications peuvent également vouloir protéger d'autres informations qui font partie de la structure de contexte. Il convient de noter que ces champs, tels que la clé ou un IV de base, qui sont protégés du fait d'être utilisés dans le calcul cryptographique, n'ont pas besoin d'être inclus dans le champ de données externe.

Le deuxième cas est d'avoir plusieurs identifiants d'algorithme implicites spécifiés pour un objet COSE à plusieurs couches. Un exemple de la façon dont cela fonctionnerait est le contexte de chiffrement qu'une application spécifie, qui contient un algorithme de chiffrement de contenu, un algorithme d'enveloppement de clé, un identifiant de clé et un secret partagé. L'expéditeur omet d'envoyer l'identifiant d'algorithme pour la couche de contenu et la couche de destinataire, ne laissant que l'identifiant de clé. Le récepteur utilise ensuite l'identifiant de clé pour obtenir les identifiants d'algorithme implicites.

Les éléments supplémentaires suivants doivent être pris en considération :

Les applications qui veulent prendre en charge cela devront définir une structure qui permet, et identifie clairement, à la fois la structure COSE à utiliser avec une clé donnée et la structure et l'algorithme à utiliser pour la couche secondaire. La clé pour la couche secondaire est calculée comme d'habitude à partir de la couche de destinataire.

Le troisième cas est d'avoir plusieurs identifiants d'algorithme implicites, mais ciblés sur des couches potentiellement non liées ou des objets COSE différents. Il existe un certain nombre de scénarios différents où cela pourrait être applicable. Certains de ces scénarios sont :

Deux contextes sont distribués par paire. Chacun des contextes est destiné à être utilisé avec un message COSE_Encrypt. Chaque contexte sera composé de clés secrètes et d'IV distincts et potentiellement même d'algorithmes différents. Un contexte est destiné à l'envoi de messages de la partie A à la partie B, et le deuxième contexte est destiné à l'envoi de messages de la partie B à la partie A. Cela signifie qu'il n'y a aucune chance qu'une attaque par réflexion se produise, car chaque partie utilise des clés secrètes différentes pour envoyer ses messages ; un message qui lui est renvoyé échouerait à être déchiffré.
Deux contextes sont distribués par paire. Le premier contexte est utilisé pour le chiffrement du message, et le deuxième contexte est utilisé pour placer une contresignature sur le message. L'intention est que le deuxième contexte puisse être distribué à d'autres entités indépendamment du premier contexte. Cela permet à ces entités de valider que le message provenait d'un individu sans pouvoir déchiffrer le message et voir le contenu.
Deux contextes sont distribués par paire. Le premier contexte contient une clé pour traiter les messages MACés, et le deuxième contexte contient une clé différente pour traiter les messages chiffrés. Cela permet une distribution unifiée des clés aux participants pour différents types de messages qui ont des clés différentes, mais où les clés peuvent être utilisées de manière coordonnée.

Pour ces cas, les éléments supplémentaires suivants doivent être considérés :

Les applications doivent s'assurer que les multiples contextes restent associés. Si l'un des contextes est invalidé pour une raison quelconque, tous les contextes associés à celui-ci devraient également être invalidés.