12. Considérations de sécurité

12. Considérations de sécurité

Il existe un certain nombre de considérations de sécurité qui doivent être prises en compte par les responsables de la mise en œuvre de cette spécification. 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ée à un deuxième algorithme de destinataire expose la clé directe au deuxième destinataire ; la section 8.5 interdit de combiner des algorithmes de destinataire "direct" avec d'autres modes.

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

L'utilisation de la courbe elliptique Diffie-Hellman (ECDH) et directe plus KDF (sans enveloppement de clé) ne conduira pas directement à la divulgation de la clé privée ; la fonction à sens unique de la 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 d'origine faible. Le deuxième destinataire pourrait créer un message en utilisant la même CEK et l'envoyer au premier destinataire ; le premier destinataire ferait, pour ECDH Static-Static 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 été mentionné auparavant, il convient de répéter que l'utilisation d'une clé unique 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 étiquettes 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 aussi à 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 les 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 ?

• Des 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") ?

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 [RFC9053]. 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 ".)