9.2. Key Usage (Utilisation des clés)
9.2. Key Usage (Utilisation des clés)
La taille effective de la clé est déterminée (bornée supérieurement) par la taille de la clé maître et, pour le chiffrement, par la taille de la clé de salage. Tout chiffrement par flux additif est vulnérable aux attaques qui utilisent des connaissances statistiques sur la source de texte clair pour permettre des attaques de collision de clés et de compromis temps-mémoire [MF00] [H80] [BS00]. Ces attaques tirent parti des points communs entre les textes clairs et fournissent un moyen pour un cryptanalyste d'amortir l'effort de calcul du déchiffrement sur de nombreuses clés ou sur de nombreux octets de sortie, réduisant ainsi la taille effective de la clé du chiffrement. Une analyse détaillée de ces attaques et de leur applicabilité au chiffrement du trafic Internet est fournie dans [MF00]. En résumé, la taille effective de la clé de SRTP lorsqu'il est utilisé dans un système de sécurité dans lequel m clés distinctes sont utilisées, est égale à la taille de la clé du chiffrement moins le logarithme (base deux) de m. La protection contre de telles attaques peut être fournie simplement en augmentant la taille des clés utilisées, ce qui peut être accompli ici par l'utilisation de la clé de salage. Notez que la clé de salage DOIT être aléatoire mais PEUT être publique. Une taille de sel de (la taille suggérée) 112 bits protège contre les attaques dans les scénarios où au plus 2^112 clés sont utilisées. Cela est suffisant pour toutes les fins pratiques.
Les implémentations DEVRAIENT utiliser des clés aussi grandes que possible. Veuillez noter que dans de nombreux cas, l'augmentation de la taille de la clé d'un chiffrement n'affecte pas le débit de ce chiffrement.
L'utilisation des indices SRTP et SRTCP dans les transformations prédéfinies fixe le nombre maximal de paquets qui peuvent être sécurisés avec la même clé. Cette limite est fixée à 2^48 paquets SRTP pour un flux SRTP, et 2^31 paquets SRTCP, lorsque SRTP et SRTCP sont considérés indépendamment. En raison par exemple du renouvellement de clé, atteindre cette limite peut ou non coïncider avec le bouclage des indices, et donc l'expéditeur DOIT tenir des comptes de paquets. Cependant, lorsque les clés de session pour les flux SRTP et SRTCP liés sont dérivées de la même clé maître (le comportement par défaut, Section 4.3), la limite supérieure qui doit être considérée est en pratique le minimum des deux quantités. C'est-à-dire que lorsque 2^48 paquets SRTP ou 2^31 paquets SRTCP ont été sécurisés avec la même clé (selon ce qui se produit en premier), la gestion des clés DOIT être appelée pour fournir de nouvelles clés maîtres (les clés précédemment stockées et utilisées NE DOIVENT PAS être réutilisées), ou la session DOIT être terminée. Si un expéditeur de RTCP découvre que l'expéditeur de SRTP (ou SRTCP) n'a pas mis à jour la clé maître ou de session avant d'envoyer 2^48 paquets SRTP (ou 2^31 paquets SRTCP) appartenant au même flux SRTP (SRTCP), il appartient à la politique de sécurité de l'expéditeur RTCP de décider comment se comporter, par exemple si un paquet RTCP BYE doit être envoyé et/ou si l'événement doit être enregistré.
Note: dans la plupart des applications typiques (en supposant au moins un paquet RTCP pour chaque 128 000 paquets RTP), ce sera l'indice SRTCP qui atteindra en premier la limite supérieure, bien que le temps jusqu'à ce que cela se produise soit très long: même à 200 paquets SRTCP/sec, l'espace d'indices 2^31 de SRTCP suffit à sécuriser environ 4 mois de communication.
Notez que si la clé maître doit être partagée entre des flux SRTP au sein de la même session RTP (Section 9.1), bien que les limites ci-dessus soient sur une base par flux (c'est-à-dire par SSRC), l'expéditeur DOIT baser la décision de renouvellement de clé sur le flux dont l'espace de numéros de séquence est le premier à être épuisé.
La dérivation de clé limite la quantité de texte clair qui est chiffré avec une clé de session fixe et mis à disposition d'un attaquant pour l'analyse, mais la dérivation de clé n'étend pas la durée de vie de la clé maître. Pour voir cela, considérez simplement nos exigences pour éviter le two-time pad: deux paquets distincts DOIVENT être traités soit avec des IV distincts, soit avec des clés de session distinctes, et la distinction de l'IV et des clés de session sont (pour les transformations prédéfinies) dépendantes de la distinction des indices de paquets.
Notez qu'avec la dérivation de clé, la taille effective de la clé est au plus celle de la clé maître, même si la clé de session dérivée est considérablement plus longue. Avec la transformation d'authentification prédéfinie, la clé d'authentification de session est de 160 bits, mais la clé maître par défaut n'est que de 128 bits. Ce choix de conception a été fait pour se conformer à certaines recommandations dans [RFC2104] afin qu'une implémentation HMAC existante puisse être intégrée à SRTP sans problèmes. Comme la taille de tag par défaut est de 80 bits, elle est, pour les applications envisagées, également considérée comme acceptable du point de vue de la sécurité. Les utilisateurs ayant des préoccupations à ce sujet sont RECOMMANDÉS d'utiliser plutôt une clé maître de 192 bits dans la dérivation de clé. Il a cependant été choisi de ne pas imposer des clés de 192 bits car les implémentations AES existantes à utiliser dans la dérivation de clé peuvent ne pas toujours prendre en charge des longueurs de clé autres que 128 bits. Comme AES n'est pas défini (ou correctement analysé) pour une utilisation avec des clés de 160 bits, il N'EST PAS RECOMMANDÉ d'utiliser des schémas de remplissage de clé ad-hoc pour remplir des clés plus courtes à 192 ou 256 bits.