3.1. Secure RTP (RTP sécurisé)
3.1. Secure RTP (RTP sécurisé)
Le format d'un paquet SRTP est illustré dans la Figure 1.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+- Encrypted Portion* Authenticated Portion ---+
Figure 1. Le format d'un paquet SRTP. *La partie chiffrée a la même taille que le texte en clair pour les transformations prédéfinies de la Section 4.
La "Encrypted Portion" (Partie chiffrée) d'un paquet SRTP consiste en le chiffrement de la charge utile RTP (y compris le rembourrage RTP lorsqu'il est présent) du paquet RTP équivalent. La partie chiffrée PEUT avoir exactement la même taille que le texte en clair ou PEUT être plus grande. La Figure 1 montre la charge utile RTP incluant tout rembourrage possible pour RTP [RFC3550].
Aucune des transformations de chiffrement prédéfinies n'utilise de rembourrage; pour celles-ci, les tailles de charge utile RTP et SRTP correspondent exactement. Les nouvelles transformations ajoutées à SRTP (suivant la Section 6) peuvent nécessiter un rembourrage et peuvent donc produire des charges utiles plus grandes. RTP fournit son propre format de rembourrage (comme on le voit dans la Fig. 1), qui, en raison de l'indicateur de rembourrage dans l'en-tête RTP, présente des avantages en termes de compacité par rapport aux rembourrages utilisant des codes sans préfixe. Ce rembourrage RTP DOIT être la méthode par défaut pour les transformations nécessitant un rembourrage. Les transformations PEUVENT spécifier d'autres méthodes de rembourrage, et DOIVENT alors spécifier la quantité, le format et le traitement de leur rembourrage. Il est important de noter que les transformations de chiffrement qui utilisent le rembourrage sont vulnérables à des attaques subtiles, en particulier lorsque l'authentification de message n'est pas utilisée [V02]. Chaque spécification pour une nouvelle transformation de chiffrement doit examiner attentivement et décrire les implications de sécurité du rembourrage qu'elle utilise. Les codes d'authentification de message définissent leur propre rembourrage, donc cette valeur par défaut ne s'applique pas aux transformations d'authentification.
Le MKI OPTIONNEL et l'authentication tag RECOMMANDÉ sont les seuls champs définis par SRTP qui ne sont pas dans RTP. Seul un alignement sur 8 bits est supposé.
MKI (Master Key Identifier, Identifiant de clé maîtresse): longueur configurable, OPTIONNEL. Le MKI est défini, signalé et utilisé par la gestion des clés. Le MKI identifie la clé maîtresse à partir de laquelle la ou les clés de session ont été dérivées pour authentifier et/ou chiffrer le paquet particulier. Notez que le MKI NE DOIT PAS identifier le contexte cryptographique SRTP, qui est identifié selon la Section 3.2.3. Le MKI PEUT être utilisé par la gestion des clés aux fins de re-clé, identifiant une clé maîtresse particulière dans le contexte cryptographique (Section 3.2.1).
Authentication tag (Étiquette d'authentification): longueur configurable, RECOMMANDÉ. L'authentication tag est utilisée pour transporter les données d'authentification de message. La Authenticated Portion (Partie authentifiée) d'un paquet SRTP consiste en l'en-tête RTP suivi de la partie chiffrée du paquet SRTP. Ainsi, si le chiffrement et l'authentification sont tous deux appliqués, le chiffrement DOIT être appliqué avant l'authentification du côté expéditeur et inversement du côté récepteur. L'authentication tag fournit l'authentification de l'en-tête et de la charge utile RTP, et elle fournit indirectement une protection contre la relecture en authentifiant le numéro de séquence. Notez que le MKI n'est pas protégé en intégrité car cela ne fournit aucune protection supplémentaire.