9.1. SSRC collision and two-time pad (Collision SSRC et two-time pad)

9.1. SSRC collision and two-time pad (Collision SSRC et two-time pad)

Toute sortie de flux de clés fixe, générée à partir de la même clé et du même index, NE DOIT être utilisée pour chiffrer qu'une seule fois. La réutilisation d'un tel flux de clés (appelé en plaisantant un système "two-time pad" par les cryptographes) peut gravement compromettre la sécurité. Le projet VENONA de la NSA [C99] fournit un exemple historique d'une telle compromise. Il est REQUIS que la gestion automatique des clés soit utilisée pour établir et maintenir le matériel de clés SRTP et SRTCP; cette exigence vise à éviter la réutilisation du flux de clés, qui est plus susceptible de se produire avec la gestion manuelle des clés. De plus, dans SRTP, un "two-time pad" est évité en exigeant que la clé, ou un autre paramètre d'importance cryptographique, soit unique par flux RTP/RTCP et par paquet. Les transformations SRTP prédéfinies réalisent l'unicité des paquets en incluant l'index de paquet et l'unicité des flux en incluant le SSRC.

Les transformations prédéfinies (AES-CM et AES-f8) permettent de partager des clés maîtres entre les flux appartenant à la même session RTP par l'inclusion du SSRC dans l'IV. Une clé maître NE DOIT PAS être partagée entre différentes sessions RTP.

Ainsi, le SSRC DOIT être unique entre tous les flux RTP au sein de la même session RTP qui partagent la même clé maître. RTP lui-même fournit un algorithme pour détecter les collisions SSRC au sein de la même session RTP. Ainsi, des collisions temporaires pourraient conduire à un two-time pad temporaire, dans le cas malheureux où les SSRC entrent en collision à un moment où les flux ont également des numéros de séquence identiques (se produisant avec une probabilité d'environ 2^(-48)). Par conséquent, la gestion des clés DEVRAIT prendre soin d'éviter de telles collisions SSRC en incluant les SSRC à utiliser dans la session comme paramètres de négociation, en assurant proactivement leur unicité. Il s'agit d'une exigence forte dans les scénarios où, par exemple, il existe plusieurs expéditeurs qui peuvent commencer à transmettre simultanément, avant que les collisions SSRC ne soient détectées au niveau RTP.

Notez également que même avec des SSRC distincts, l'utilisation intensive de la même clé pourrait améliorer les chances de réussite des attaques de collision probabiliste et de compromis temps-mémoire.

Comme décrit, les clés maîtres PEUVENT être partagées entre les flux appartenant à la même session RTP, mais il est RECOMMANDÉ que chaque SSRC ait sa propre clé maître. Lorsque les clés maîtres sont partagées entre les participants SSRC et que les SSRC sont gérés par un module de gestion des clés comme recommandé ci-dessus, la politique RECOMMANDÉE pour une erreur de collision SSRC est que le participant quitte la session SRTP car c'est un signe de dysfonctionnement.