9.5. Integrity of the RTP payload and header (Intégrité de la charge utile et de l'en-tête RTP)
9.5. Integrity of the RTP payload and header (Intégrité de la charge utile et de l'en-tête RTP)
Les messages SRTP sont sujets à des attaques sur leur intégrité et l'identification de la source, et ces risques sont discutés dans la Section 9.5.1. Pour se protéger contre ces attaques, chaque flux SRTP DEVRAIT être protégé par HMAC-SHA1 [RFC2104] avec une étiquette de sortie de 80 bits et une clé de 160 bits, ou un code d'authentification de message de force équivalente. RTP sécurisé NE DEVRAIT PAS être utilisé sans authentification de message, sauf dans les circonstances décrites dans cette section. Il est important de noter que les algorithmes de chiffrement, y compris le mode compteur AES et f8, ne fournissent pas d'authentification de message. SRTCP NE DOIT PAS être utilisé avec une authentification faible (ou NULL).
SRTP PEUT être utilisé avec une authentification faible (par exemple, une étiquette d'authentification de 32 bits), ou sans authentification (l'algorithme d'authentification NULL). Ces options permettent d'utiliser SRTP pour fournir la confidentialité dans des situations où
- l'authentification faible ou nulle est un risque de sécurité acceptable, et
- il est impraticable de fournir une authentification de message forte.
Ces conditions sont décrites ci-dessous et dans la Section 7.5. Notez que les deux conditions DOIVENT être remplies pour que l'authentification faible ou nulle soit utilisée. Les risques associés à l'exercice des options d'authentification faible ou nulle doivent être pris en compte par un audit de sécurité avant leur utilisation pour une application ou un environnement particulier compte tenu des risques, qui sont discutés dans la Section 9.5.1.
L'authentification faible est acceptable lorsque l'application RTP est telle que l'effet d'une petite fraction de contrefaçons réussies est négligeable. Si l'application est sans état, alors l'effet d'un seul paquet RTP falsifié est limité au décodage de ce paquet particulier. Dans cette condition, la taille de l'étiquette d'authentification DOIT garantir que seule une fraction négligeable des paquets transmis à l'application RTP par le récepteur SRTP peut être des contrefaçons. Cette fraction est négligeable lorsqu'un adversaire, s'il a le contrôle des paquets falsifiés, n'est pas capable d'avoir un impact significatif sur la sortie de l'application RTP (voir l'exemple de la Section 7.5).
L'authentification faible ou nulle PEUT être acceptable lorsqu'il est peu probable qu'un adversaire puisse modifier le texte chiffré de sorte qu'il se déchiffre en une valeur intelligible. Un cas important est celui où il est difficile pour un adversaire d'acquérir les données de texte clair RTP, car pour de nombreux codecs, un adversaire qui ne connaît pas le signal d'entrée ne peut pas manipuler le signal de sortie de manière contrôlée. Dans de nombreux cas, il peut être difficile pour l'adversaire de déterminer la valeur réelle du texte clair. Par exemple, un dispositif d'espionnage caché pourrait être nécessaire pour connaître un signal audio ou vidéo en direct. Le signal de l'adversaire doit avoir une qualité équivalente ou supérieure à celle du signal attaqué, sinon l'adversaire n'aurait pas assez d'informations pour encoder ce signal avec le codec utilisé par la victime. La prédiction du texte clair peut également être particulièrement difficile pour une application interactive telle qu'un appel téléphonique.
L'authentification faible ou nulle NE DOIT PAS être utilisée lorsque l'application RTP prend des décisions de transfert de données ou de contrôle d'accès basées sur les données RTP. Dans un tel cas, un attaquant peut être capable de subvertir la confidentialité en faisant en sorte que le récepteur transfère des données à un attaquant. Voir la Section 3 de [B96] pour un exemple réel de telles attaques.
L'authentification nulle NE DOIT PAS être utilisée lorsqu'une attaque par rejeu, dans laquelle un adversaire stocke des paquets puis les rejoue plus tard dans la session, pourrait avoir un impact non négligeable sur le récepteur. Un exemple d'attaque par rejeu réussie est le stockage de la sortie d'une caméra de surveillance pendant une période de temps, suivi de l'injection de cette sortie vers la station de surveillance pour éviter la surveillance. Le chiffrement ne protège pas contre cette attaque, et une authentification non nulle est REQUISE pour la vaincre.
Si la falsification de message existentielle est un problème, c'est-à-dire lorsque l'exactitude des données reçues est d'une importance non négligeable, l'authentification nulle NE DOIT PAS être utilisée.