4. Algorithmes de Chiffrement de Contenu

4. Algorithmes de Chiffrement de Contenu

La section 8.3 de [RFC9052] contient une description générique des algorithmes de chiffrement de contenu. Ce document définit l'identifiant et les usages pour trois algorithmes de chiffrement de contenu.

4.1. AES-GCM

Le mode Galois/Counter Mode (GCM) est un mode de chiffrement par bloc AEAD générique défini dans [AES-GCM]. Le mode GCM est combiné avec l'algorithme de chiffrement par bloc AES pour définir un chiffrement AEAD.

Le mode GCM est paramétré par la taille de l'étiquette d'authentification et la taille du nonce. Ce document fixe la taille du nonce à 96 bits. La taille de l'étiquette d'authentification est limitée à un petit ensemble de valeurs. Pour ce document, cependant, la taille de l'étiquette d'authentification est fixée à 128 bits.

L'ensemble des algorithmes définis dans ce document se trouve dans le Tableau 5.

  +=========+=======+==========================================+
  | Nom     | Valeur| Description                              |
  +=========+=======+==========================================+
  | A128GCM |   1   | Mode AES-GCM avec clé 128 bits,          |
  |         |       | étiquette 128 bits                       |
  +---------+-------+------------------------------------------+
  | A192GCM |   2   | Mode AES-GCM avec clé 192 bits,          |
  |         |       | étiquette 128 bits                       |
  +---------+-------+------------------------------------------+
  | A256GCM |   3   | Mode AES-GCM avec clé 256 bits,          |
  |         |       | étiquette 128 bits                       |
  +---------+-------+------------------------------------------+

              Tableau 5: Valeurs d'algorithme pour AES-GCM

Les clés peuvent être obtenues à partir d'une structure de clé ou d'une structure de destinataire. Les implémentations qui chiffrent ou déchiffrent DOIVENT valider que le type de clé, la longueur de clé et l'algorithme sont corrects et appropriés pour les entités impliquées.

Lors de l'utilisation d'une clé COSE pour cet algorithme, les vérifications suivantes sont effectuées :

• Le champ "kty" DOIT être présent, et il DOIT être "Symmetric".

• Si le champ "alg" est présent, il DOIT correspondre à l'algorithme AES-GCM utilisé.

• Si le champ "key_ops" est présent, il DOIT inclure "encrypt" ou "wrap key" lors du chiffrement.

• Si le champ "key_ops" est présent, il DOIT inclure "decrypt" ou "unwrap key" lors du déchiffrement.

4.1.1. Considérations de sécurité pour AES-GCM

Lors de l'utilisation d'AES-GCM, les restrictions suivantes DOIVENT être appliquées :

• La paire clé et nonce DOIT être unique pour chaque message chiffré.

• Le nombre total de messages chiffrés pour une seule clé NE DOIT PAS dépasser 2^32 [SP800-38D]. Une vérification explicite n'est requise que dans les environnements où l'on s'attend à ce que cette limite puisse être dépassée.

• [RFC8446] contient une analyse sur l'utilisation d'AES-CGM pour son environnement. Sur la base de cette recommandation, on devrait restreindre le nombre de messages chiffrés à 2^24.5.

• Une analyse plus récente dans [ROBUST] indique que le nombre d'échecs de déchiffrement doit être pris en compte pour déterminer quand un renouvellement de clé doit être effectué. Suivant la recommandation de DTLS (Section 4.5.3 de [RFC9147]), le nombre d'échecs de déchiffrement de message devrait être limité à 2^36.

Il a été envisagé de prendre en charge des valeurs d'étiquette plus petites ; la communauté contrainte souhaiterait des tailles d'étiquette dans la plage de 64 bits. Une telle utilisation modifie radicalement à la fois la taille maximale du message (généralement pas un problème) et le nombre de fois qu'une clé peut être utilisée. Étant donné que le compteur avec CBC-MAC (CCM) est le mode habituel pour les environnements contraints, les modes restreints ne sont pas pris en charge.

4.2. AES-CCM

CCM est un mode de chiffrement par bloc d'authentification générique défini dans [RFC3610]. Le mode CCM est combiné avec l'algorithme de chiffrement par bloc AES pour définir un chiffrement AEAD qui est couramment utilisé dans les appareils contraints.

Le mode CCM a deux choix de paramètres. Le premier choix est M, la taille du champ d'authentification. Le choix de la valeur pour M implique un compromis entre la croissance du message (à partir de l'étiquette) et la probabilité qu'un attaquant puisse modifier un message de manière indétectable. Le deuxième choix est L, la taille du champ de longueur. Cette valeur nécessite un compromis entre la taille maximale du message et la taille du nonce.

Il est regrettable que la spécification de CCM ait spécifié L et M comme un nombre d'octets plutôt qu'un nombre de bits. Cela conduit à des malentendus possibles où AES-CCM-8 est fréquemment utilisé pour faire référence à une version du mode CCM où la taille de l'authentification est de 64 bits et non de 8 bits. Dans la plupart des spécifications d'algorithmes cryptographiques, ces valeurs ont traditionnellement été spécifiées en nombre de bits plutôt qu'en nombre d'octets. Ce document suivra la convention d'utiliser des nombres de bits afin qu'il soit plus facile de comparer les différents algorithmes présentés dans ce document.

Nous définissons une matrice d'algorithmes dans ce document sur les valeurs de L et M. Les appareils contraints fonctionnent généralement dans des situations où ils utilisent des messages courts et veulent éviter de faire des opérations cryptographiques spécifiques au destinataire. Cela favorise des valeurs plus petites de L et M. Les appareils moins contraints voudront pouvoir utiliser des messages plus volumineux et sont plus disposés à générer de nouvelles clés pour chaque opération. Cela favorise des valeurs plus grandes de L et M.

Les valeurs suivantes sont utilisées pour L :

16 bits (2): Cela limite les messages à 2^16 octets (64 Kio) de longueur. C'est suffisamment long pour les messages dans le monde contraint. La longueur du nonce est de 13 octets, permettant 2^104 valeurs possibles du nonce sans répétition.

64 bits (8): Cela limite les messages à 2^64 octets de longueur. La longueur du nonce est de 7 octets, permettant 2^56 valeurs possibles du nonce sans répétition.

Les valeurs suivantes sont utilisées pour M :

64 bits (8): Cela produit une étiquette d'authentification de 64 bits. Cela implique qu'il y a une chance de 1 sur 2^64 qu'un message modifié soit authentifié.

128 bits (16): Cela produit une étiquette d'authentification de 128 bits. Cela implique qu'il y a une chance de 1 sur 2^128 qu'un message modifié soit authentifié.

+====================+=======+====+=====+========+===============+
| Nom                | Valeur| L  | M   | Long.  | Description   |
|                    |       |    |     | Clé    |               |
+====================+=======+====+=====+========+===============+
| AES-CCM-16-64-128  |   10  | 16 | 64  |  128   | Mode AES-CCM  |
|                    |       |    |     |        | clé 128 bits, |
|                    |       |    |     |        | étiquette 64  |
|                    |       |    |     |        | bits, nonce   |
|                    |       |    |     |        | 13 octets     |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-64-256  |   11  | 16 | 64  |  256   | Mode AES-CCM  |
|                    |       |    |     |        | clé 256 bits, |
|                    |       |    |     |        | étiquette 64  |
|                    |       |    |     |        | bits, nonce   |
|                    |       |    |     |        | 13 octets     |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-128  |   12  | 64 | 64  |  128   | Mode AES-CCM  |
|                    |       |    |     |        | clé 128 bits, |
|                    |       |    |     |        | étiquette 64  |
|                    |       |    |     |        | bits, nonce   |
|                    |       |    |     |        | 7 octets      |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-256  |   13  | 64 | 64  |  256   | Mode AES-CCM  |
|                    |       |    |     |        | clé 256 bits, |
|                    |       |    |     |        | étiquette 64  |
|                    |       |    |     |        | bits, nonce   |
|                    |       |    |     |        | 7 octets      |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-128 |   30  | 16 | 128 |  128   | Mode AES-CCM  |
|                    |       |    |     |        | clé 128 bits, |
|                    |       |    |     |        | étiquette 128 |
|                    |       |    |     |        | bits, nonce   |
|                    |       |    |     |        | 13 octets     |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-256 |   31  | 16 | 128 |  256   | Mode AES-CCM  |
|                    |       |    |     |        | clé 256 bits, |
|                    |       |    |     |        | étiquette 128 |
|                    |       |    |     |        | bits, nonce   |
|                    |       |    |     |        | 13 octets     |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-128 |   32  | 64 | 128 |  128   | Mode AES-CCM  |
|                    |       |    |     |        | clé 128 bits, |
|                    |       |    |     |        | étiquette 128 |
|                    |       |    |     |        | bits, nonce   |
|                    |       |    |     |        | 7 octets      |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-256 |   33  | 64 | 128 |  256   | Mode AES-CCM  |
|                    |       |    |     |        | clé 256 bits, |
|                    |       |    |     |        | étiquette 128 |
|                    |       |    |     |        | bits, nonce   |
|                    |       |    |     |        | 7 octets      |
+--------------------+-------+----+-----+--------+---------------+

              Tableau 6: Valeurs d'algorithme pour AES-CCM

Les clés peuvent être obtenues à partir d'une structure de clé ou d'une structure de destinataire. Les implémentations qui chiffrent ou déchiffrent DOIVENT valider que le type de clé, la longueur de clé et l'algorithme sont corrects et appropriés pour les entités impliquées.

Lors de l'utilisation d'une clé COSE pour cet algorithme, les vérifications suivantes sont effectuées :

• Le champ "kty" DOIT être présent, et il DOIT être "Symmetric".

• Si le champ "alg" est présent, il DOIT correspondre à l'algorithme AES-CCM utilisé.

• Si le champ "key_ops" est présent, il DOIT inclure "encrypt" ou "wrap key" lors du chiffrement.

• Si le champ "key_ops" est présent, il DOIT inclure "decrypt" ou "unwrap key" lors du déchiffrement.

4.2.1. Considérations de sécurité pour AES-CCM

Lors de l'utilisation d'AES-CCM, les restrictions suivantes DOIVENT être appliquées :

• La paire clé et nonce DOIT être unique pour chaque message chiffré. Notez que la valeur de L influence le nombre de nonces uniques.

• Le nombre total de fois que le chiffrement par bloc AES est utilisé NE DOIT PAS dépasser 2^61 opérations. Cette limite est la somme des fois où le chiffrement par bloc est utilisé pour calculer la valeur MAC et effectuer les opérations de chiffrement de flux. Une vérification explicite n'est requise que dans les environnements où l'on s'attend à ce que cette limite puisse être dépassée.

• [RFC9147] contient une analyse sur l'utilisation d'AES-CCM pour son environnement. Sur la base de cette recommandation, on devrait restreindre le nombre de messages chiffrés à 2^23.

• En plus du nombre de messages déchiffrés avec succès, le nombre d'échecs de déchiffrement doit également être suivi. Suivant la recommandation de DTLS (Section 4.5.3 de [RFC9147]), le nombre d'échecs de déchiffrement de message devrait être limité à 2^23.5. Si l'on utilise l'étiquette de 64 bits, alors les limites sont nettement plus petites si l'on veut conserver les mêmes limites d'intégrité. Un protocole recommandant cela doit analyser quel niveau d'intégrité est acceptable pour la taille d'étiquette plus petite. Il se peut que, pour conserver le niveau d'intégrité souhaité, il soit nécessaire de changer de clé aussi souvent que tous les 2^7 messages.

[RFC3610] appelle en outre une autre considération notable. Il est possible de faire une attaque par précalcul contre l'algorithme dans les cas où des portions du texte clair sont hautement prévisibles. Cela réduit la sécurité de la taille de la clé de moitié. Les moyens de faire face à cette attaque incluent l'ajout d'une partie aléatoire à la valeur du nonce et/ou l'augmentation de la taille de la clé utilisée. L'utilisation d'une partie du nonce pour une valeur aléatoire diminuera le nombre de messages pour lesquels une seule clé peut être utilisée. L'augmentation de la taille de la clé peut nécessiter plus de ressources dans l'appareil contraint. Voir les sections 5 et 10 de [RFC3610] pour plus d'informations.

4.3. ChaCha20 et Poly1305

ChaCha20 et Poly1305 combinés ensemble est un mode AEAD qui est défini dans [RFC8439]. C'est un algorithme défini utilisant un chiffrement qui n'est pas AES et ne souffrirait donc d'aucune faiblesse future trouvée dans AES. Ces fonctions cryptographiques sont conçues pour être rapides dans les implémentations logicielles uniquement.

La construction AEAD ChaCha20/Poly1305 définie dans [RFC8439] n'a pas de paramétrage. Elle prend en entrée une clé de 256 bits et un nonce de 96 bits, ainsi que le texte clair et des données supplémentaires, et produit le texte chiffré en sortie. Nous définissons un identifiant d'algorithme pour cet algorithme dans le Tableau 7.

     +===================+=======+==========================+
     | Nom               | Valeur| Description              |
     +===================+=======+==========================+
     | ChaCha20/Poly1305 |   24  | ChaCha20/Poly1305 avec   |
     |                   |       | clé 256 bits, étiquette  |
     |                   |       | 128 bits                 |
     +-------------------+-------+--------------------------+

          Tableau 7: Valeur d'algorithme pour ChaCha20/Poly1305

Les clés peuvent être obtenues à partir d'une structure de clé ou d'une structure de destinataire. Les implémentations qui chiffrent ou déchiffrent DOIVENT valider que le type de clé, la longueur de clé et l'algorithme sont corrects et appropriés pour les entités impliquées.

Lors de l'utilisation d'une clé COSE pour cet algorithme, les vérifications suivantes sont effectuées :

• Le champ "kty" DOIT être présent, et il DOIT être "Symmetric".

• Si le champ "alg" est présent, il DOIT correspondre à l'algorithme ChaCha20/Poly1305 utilisé.

• Si le champ "key_ops" est présent, il DOIT inclure "encrypt" ou "wrap key" lors du chiffrement.

• Si le champ "key_ops" est présent, il DOIT inclure "decrypt" ou "unwrap key" lors du déchiffrement.

4.3.1. Considérations de sécurité pour ChaCha20/Poly1305

Les valeurs de clé et de nonce DOIVENT être une paire unique pour chaque invocation de l'algorithme. Les compteurs de nonce sont considérés comme un moyen acceptable de s'assurer qu'ils sont uniques.

Une analyse plus récente dans [ROBUST] indique que le nombre d'échecs de déchiffrement doit être pris en compte pour déterminer quand un renouvellement de clé doit être effectué. Suivant la recommandation de DTLS (Section 4.5.3 de [RFC9147]), le nombre d'échecs de déchiffrement de message devrait être limité à 2^36.

[RFC8446] note que le numéro de séquence d'enregistrement (64 bits) s'enroulerait avant que la limite de sécurité ne soit atteinte pour ChaCha20/Poly1305. Les implémentations COSE ne devraient pas envoyer plus de 2^64 messages chiffrés en utilisant une seule clé ChaCha20/Poly1305.