11. Considérations de sécurité

11. Considérations de sécurité

Il existe un certain nombre de considérations de sécurité qui doivent être prises en compte par les implémenteurs de cette spécification. Les considérations de sécurité spécifiques à un algorithme individuel sont placées à côté de la description de l'algorithme. Bien que certaines considérations aient été soulignées ici, des considérations supplémentaires peuvent être trouvées dans les documents énumérés dans les références.

Les implémentations doivent protéger le matériel de clé privée pour tous les individus. Certains cas dans ce document doivent être soulignés en ce qui concerne cette question.

• L'utilisation de la même clé pour deux algorithmes différents peut divulguer des informations sur la clé. Il est donc recommandé que les clés soient limitées à un seul algorithme.

• L'utilisation de "direct" comme algorithme de destinataire combiné à un deuxième algorithme de destinataire expose la clé directe au deuxième destinataire ; la section 8.5 de [RFC9052] interdit de combiner des algorithmes de destinataire "direct" avec d'autres modes.

• Plusieurs des algorithmes de ce document ont des limites sur le nombre de fois qu'une clé peut être utilisée sans divulguer d'informations sur la clé.

L'utilisation d'ECDH et de direct plus KDF (sans enveloppement de clé) ne conduira pas directement à la divulgation de la clé privée ; la fonction à sens unique du KDF empêchera cela. Il y a cependant un problème différent qui doit être résolu. Avoir deux destinataires nécessite que la CEK soit partagée entre deux destinataires. Le deuxième destinataire a donc une CEK qui a été dérivée d'un matériel qui peut être utilisé pour la preuve faible d'origine. Le deuxième destinataire pourrait créer un message utilisant la même CEK et l'envoyer au premier destinataire ; le premier destinataire ferait, pour Static-Static ECDH ou direct plus KDF, l'hypothèse que la CEK pourrait être utilisée pour la preuve d'origine, même si elle provient de la mauvaise entité. Si l'étape d'enveloppement de clé est ajoutée, alors aucune preuve d'origine n'est impliquée et ce n'est pas un problème.

Bien que cela ait déjà été mentionné, il convient de répéter que l'utilisation d'une seule clé pour plusieurs algorithmes a été démontrée dans certains cas pour divulguer des informations sur une clé, offrant aux attaquants la possibilité de falsifier des balises d'intégrité ou d'obtenir des informations sur le contenu chiffré. Lier une clé à un seul algorithme empêche ces problèmes. Les créateurs de clés et les consommateurs de clés sont fortement encouragés non seulement à créer de nouvelles clés pour chaque algorithme différent, mais à inclure cette sélection d'algorithme dans toute distribution de matériel de clé et à appliquer strictement la correspondance des algorithmes dans la structure de clé aux algorithmes dans la structure de message. En plus de vérifier que les algorithmes sont corrects, la forme de la clé doit également être vérifiée. N'utilisez pas une clé "EC2" là où une clé "OKP" est attendue.

Avant d'utiliser une clé pour la transmission, ou avant d'agir sur des informations reçues, une décision de confiance sur une clé doit être prise. Les données ou l'action sont-elles quelque chose que l'entité associée à la clé a le droit de voir ou le droit de demander ? Un certain nombre de facteurs sont associés à cette décision de confiance. Certains soulignés ici sont :

• Quelles sont les autorisations associées au propriétaire de la clé ?

• L'algorithme cryptographique est-il acceptable dans le contexte actuel ?

• Les restrictions associées à la clé, telles que l'algorithme ou la fraîcheur, ont-elles été vérifiées, et sont-elles correctes ?

• La demande est-elle raisonnable, compte tenu de l'état actuel de l'application ?

• Toutes les considérations de sécurité qui font partie du message ont-elles été appliquées (telles que spécifiées par l'application ou le paramètre d'en-tête "crit") ?

Il existe un grand nombre d'algorithmes présentés dans ce document qui utilisent des valeurs de nonce. Pour tous les nonces définis dans ce document, il existe un certain type de restriction sur le fait que le nonce soit une valeur unique pour une clé ou d'autres conditions. Dans tous ces cas, il n'y a aucune exigence connue pour que le nonce soit à la fois unique et imprévisible ; dans ces circonstances, il est raisonnable d'utiliser un compteur pour la création du nonce. Dans les cas où l'on souhaite que le motif du nonce soit imprévisible ainsi qu'unique, on peut utiliser une clé créée à cet effet et chiffrer le compteur pour produire la valeur du nonce.

Un domaine qui a été exposé est l'analyse du trafic des messages chiffrés basée sur la longueur du message. Cette spécification ne fournit pas de méthode uniforme pour fournir un remplissage (padding) dans le cadre de la structure du message. Un observateur peut faire la distinction entre deux messages différents (par exemple, "OUI" et "NON") en fonction de la longueur pour tous les algorithmes de chiffrement de contenu définis dans ce document. Cela signifie qu'il appartient aux applications de documenter comment le remplissage du contenu doit être effectué afin d'empêcher ou de décourager une telle analyse. (Par exemple, les chaînes de texte pourraient être définies comme "OUI" et "NON ".)

L'analyse effectuée dans [RFC9147] est basée sur le nombre d'enregistrements envoyés. Cela devrait bien correspondre au nombre de messages envoyés lors de l'utilisation de COSE, de sorte que l'analyse devrait également s'appliquer ici, en supposant que les messages COSE ont à peu près la même taille que les enregistrements DTLS. Il convient de noter que les limites sont basées sur le nombre de messages, mais QUIC et DTLS sont toujours des points de terminaison par paires. En revanche, [OSCORE-GROUPCOMM] utilise COSE dans un scénario de communication de groupe. Dans ces circonstances, il se peut qu'aucune entité unique ne voie tous les messages chiffrés, et donc aucune entité unique ne peut déclencher l'opération de renouvellement de clé.