4.1.1. AES in Counter Mode (AES en mode compteur)
4.1.1. AES in Counter Mode (AES en mode compteur)
Conceptuellement, le mode compteur [AES-CTR] consiste à chiffrer des entiers successifs. La définition réelle est quelque peu plus compliquée, afin de randomiser le point de départ de la séquence d'entiers. Chaque paquet est chiffré avec un segment de flux de clés distinct, qui DOIT être calculé comme suit.
Un segment de flux de clés DOIT être la concaténation des blocs de sortie de 128 bits du chiffrement AES dans le sens du chiffrement, en utilisant la clé k = k_e, dans laquelle les indices de bloc sont en ordre croissant. Symboliquement, chaque segment de flux de clés ressemble à
E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...
où la valeur entière de 128 bits IV DOIT être définie par le SSRC, l'index de paquet SRTP i, et la clé de salage de session SRTP k_s, comme ci-dessous.
IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)
Chacun des trois termes de la somme XOR ci-dessus est complété par autant de zéros de tête que nécessaire pour rendre l'opération bien définie, considérée comme une valeur de 128 bits.
L'inclusion du SSRC permet l'utilisation de la même clé pour protéger des flux SRTP distincts au sein de la même session RTP, voir les mises en garde de sécurité dans la Section 9.1.
Dans le cas de SRTCP, le SSRC du premier en-tête du paquet composé DOIT être utilisé, i DOIT être l'index SRTCP de 31 bits et k_e, k_s DOIVENT être remplacés par la clé de session de chiffrement SRTCP et le sel.
Notez que la valeur initiale, IV, est fixe pour chaque paquet et est formée en "réservant" 16 zéros dans les bits les moins significatifs à des fins de compteur. Le nombre de blocs de flux de clés générés pour toute valeur fixe de IV NE DOIT PAS dépasser 2^16 pour éviter la réutilisation du flux de clés, voir ci-dessous. L'AES a une taille de bloc de 128 bits, donc 2^16 blocs de sortie sont suffisants pour générer les 2^23 bits de flux de clés nécessaires pour chiffrer le plus grand paquet RTP possible (à l'exception des "jumbograms" IPv6 [RFC2675], qui ne sont pas susceptibles d'être utilisés pour le trafic multimédia basé sur RTP). Cette restriction sur la taille maximale en bits du paquet pouvant être chiffré garantit la sécurité de la méthode de chiffrement en limitant l'efficacité des attaques probabilistes [BDJR].
Pour une clé de mode compteur particulière, chaque valeur IV utilisée comme entrée DOIT être distincte, afin d'éviter l'exposition de sécurité d'une situation de bloc à usage unique utilisé deux fois (Section 9.1). Pour satisfaire cette contrainte, une implémentation DOIT s'assurer que la combinaison de l'index de paquet SRTP de ROC || SEQ, et du SSRC utilisé dans la construction de l'IV sont distincts pour toute clé particulière. L'échec à assurer cette unicité pourrait être catastrophique pour le RTP sécurisé. Cela contraste avec la situation pour RTP lui-même, qui peut être en mesure de tolérer de telles défaillances. Il est RECOMMANDÉ que, si un module de sécurité dédié est présent, les numéros de séquence RTP et le SSRC soient soit générés soit vérifiés par ce module (c'est-à-dire que le traitement des numéros de séquence et du SSRC dans un système SRTP doit être protégé aussi bien que la clé).