Aller au contenu principal

3.14. Encrypted Payload

3.14. Encrypted Payload​

Le Encrypted payload, désigné SK {...} dans le présent document, contient d'autres charges utiles sous forme chiffrée. Si un Encrypted payload est présent dans un message, il DOIT être la dernière charge utile du message. Souvent, c'est la seule charge utile du message. Cette charge utile est aussi appelée la charge utile « Encrypted and Authenticated ».

Les algorithmes de chiffrement et de protection d'intégrité sont négociés lors de l'établissement de l'IKE SA, et les clés sont calculées comme spécifié aux sections 2.14 et 2.18.

Le présent document spécifie le traitement cryptographique des Encrypted payloads à l'aide d'un chiffrement par blocs en mode CBC et d'un algorithme de contrôle d'intégrité qui calcule une somme de contrôle de longueur fixe sur un message de taille variable. La conception est calquée sur les algorithmes ESP décrits dans les RFC 2104 [HMAC], 4303 [ESP] et 2451 [ESPCBC]. Le présent document spécifie entièrement le traitement cryptographique des données IKE, mais ces documents doivent être consultés pour la justification de conception. Des documents futurs PEUVENT spécifier le traitement des Encrypted payloads pour d'autres types de transformations, tels que le chiffrement en mode compteur et les algorithmes de chiffrement authentifié. Les pairs NE DOIVENT PAS négocier de transformations pour lesquelles aucune spécification de ce type n'existe.

Lorsqu'un algorithme de chiffrement authentifié est utilisé pour protéger l'IKE SA, la construction de l'Encrypted payload diffère de ce qui est décrit ici. Voir [AEAD] pour plus d'informations sur les algorithmes de chiffrement authentifié et leur utilisation dans IKEv2.

Le type de charge utile pour un Encrypted payload est quarante-six (46). L'Encrypted payload consiste en l'en-tête générique de charge utile IKE suivi des champs individuels suivants :

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Initialization Vector                     |
|         (length is block size for encryption algorithm)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Encrypted IKE Payloads                     ~
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |             Padding (0-255 octets)            |
+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
|                                               |  Pad Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Integrity Checksum Data                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 21 : Format de l'Encrypted payload

  • Next Payload - Le type de charge utile de la première charge utile imbriquée. Ceci est une exception au format d'en-tête standard, car l'Encrypted payload est la dernière charge utile du message et le champ Next Payload serait donc normalement zéro. Mais comme le contenu de cette charge utile est constitué de charges utiles imbriquées et qu'il n'y avait pas d'emplacement naturel pour le type de la première, ce type est placé ici.

  • Payload Length - Inclut les longueurs de l'en-tête, du vecteur d'initialisation (IV), des IKE payloads chiffrés, du Padding, du Pad Length et des Integrity Checksum Data.

  • Initialization Vector - Pour les chiffrements en mode CBC, la longueur du vecteur d'initialisation (IV) est égale à la longueur de bloc de l'algorithme de chiffrement sous-jacent. Les émetteurs DOIVENT sélectionner un nouvel IV imprévisible pour chaque message ; les destinataires DOIVENT accepter toute valeur. Le lecteur est invité à consulter [MODES] pour des conseils sur la génération d'IV. En particulier, l'utilisation du dernier bloc de texte chiffré du message précédent n'est pas considérée comme imprévisible. Pour des modes autres que CBC, le format et le traitement de l'IV sont spécifiés dans le document définissant l'algorithme de chiffrement et le mode.

  • Les IKE payloads sont comme spécifié plus haut dans cette section. Ce champ est chiffré avec le chiffre négocié.

  • Le Padding PEUT contenir toute valeur choisie par l'émetteur et DOIT avoir une longueur telle que la combinaison des charges utiles, du Padding et du Pad Length soit un multiple de la taille de bloc du chiffrement. Ce champ est chiffré avec le chiffre négocié.

  • Pad Length est la longueur du champ Padding. L'émetteur DEVRAIT régler Pad Length à la valeur minimale qui rend la combinaison des charges utiles, du Padding et du Pad Length multiple de la taille de bloc, mais le destinataire DOIT accepter toute longueur qui assure un alignement correct. Ce champ est chiffré avec le chiffre négocié.

  • Integrity Checksum Data est la somme de contrôle cryptographique de l'ensemble du message depuis l'en-tête IKE fixe jusqu'au Pad Length. La somme de contrôle DOIT être calculée sur le message chiffré. Sa longueur est déterminée par l'algorithme d'intégrité négocié.

Dernière mise à jour le