Aller au contenu principal

9. Security (Sécurité)

Les protocoles de couche inférieure peuvent éventuellement fournir tous les services de sécurité qui peuvent être désirés pour les applications de RTP, incluant l'authentification, l'intégrité et la confidentialité. Ces services ont été spécifiés pour IP dans [27]. Puisque les applications audio et vidéo initiales utilisant RTP avaient besoin d'un service de confidentialité avant que de tels services ne soient disponibles pour la couche IP, le service de confidentialité décrit dans la section suivante a été défini pour être utilisé avec RTP et RTCP. Cette description est incluse ici pour codifier la pratique existante. De nouvelles applications de RTP PEUVENT implémenter ce service de confidentialité spécifique à RTP pour la compatibilité ascendante, et/ou elles PEUVENT implémenter des services de sécurité alternatifs. La surcharge sur le protocole RTP pour ce service de confidentialité est faible, de sorte que la pénalité sera minimale si ce service est rendu obsolète par d'autres services dans le futur.

Alternativement, d'autres services, d'autres implémentations de services et d'autres algorithmes peuvent être définis pour RTP dans le futur. En particulier, un profil RTP appelé Protocole de transport en temps réel sécurisé (SRTP, Secure Real-time Transport Protocol) [28] est en cours de développement pour fournir la confidentialité de la charge utile RTP tout en laissant l'en-tête RTP en clair afin que les algorithmes de compression d'en-tête au niveau liaison puissent encore fonctionner. Il est attendu que SRTP soit le bon choix pour de nombreuses applications. SRTP est basé sur le Standard de chiffrement avancé (AES, Advanced Encryption Standard) et fournit une sécurité plus forte que le service décrit ici. Aucune affirmation n'est faite que les méthodes présentées ici conviennent à un besoin de sécurité particulier. Un profil peut spécifier quels services et algorithmes devraient être offerts par les applications, et peut fournir des conseils quant à leur usage approprié.

La distribution des clés et les certificats dépassent le cadre de ce document.

9.1 Confidentiality (Confidentialité)​

La confidentialité signifie que seuls les récepteurs visés peuvent décoder les paquets reçus ; pour les autres, le paquet ne contient aucune information utile. La confidentialité du contenu est obtenue par le chiffrement.

Quand il est souhaité de chiffrer RTP ou RTCP selon la méthode spécifiée dans cette section, tous les octets qui seront encapsulés pour la transmission dans un seul paquet de couche inférieure sont chiffrés en tant qu'unité. Pour RTCP, un nombre aléatoire de 32 bits redrawn pour chaque unité DOIT être préfixé à l'unité avant le chiffrement. Pour RTP, aucun préfixe n'est préfixé ; à la place, les champs de numéro de séquence et d'horodatage sont initialisés avec des décalages aléatoires. Ceci est considéré comme un vecteur d'initialisation (IV) faible en raison de ses mauvaises propriétés d'aléatoire. De plus, si le champ suivant, le SSRC, peut être manipulé par un ennemi, il y a une faiblesse supplémentaire de la méthode de chiffrement.

Pour RTCP, une implémentation PEUT séparer les paquets RTCP individuels dans un paquet RTCP composé en deux paquets RTCP composés distincts, l'un à chiffrer et l'autre à envoyer en clair. Par exemple, l'information SDES pourrait être chiffrée tandis que les rapports de réception seraient envoyés en clair pour accommoder des moniteurs tiers qui ne sont pas au courant de la clé de chiffrement. Dans cet exemple, dépeint à la figure 4, l'information SDES DOIT être ajoutée à la suite d'un paquet RR sans rapports (et du nombre aléatoire) pour satisfaire à l'exigence que tous les paquets RTCP composés commencent par un paquet SR ou RR. L'élément SDES CNAME est requis soit dans le paquet chiffré soit dans le paquet non chiffré, mais pas dans les deux. La même information SDES NE DEVRAIT PAS être transportée dans les deux paquets car cela pourrait compromettre le chiffrement.

            UDP packet                     UDP packet
  -----------------------------  ------------------------------
  [random][RR][SDES #CNAME ...]  [SR #senderinfo #site1 #site2]
  -----------------------------  ------------------------------
            encrypted                     not encrypted

  #: SSRC identifier

      Figure 4: Encrypted and non-encrypted RTCP packets

La présence du chiffrement et l'usage de la clé correcte sont confirmés par le récepteur par des vérifications de validité d'en-tête ou de charge utile. Des exemples de telles vérifications de validité pour les en-têtes RTP et RTCP sont donnés aux appendices A.1 et A.2.

Pour être cohérent avec les implémentations existantes de la spécification initiale de RTP dans la RFC 1889, l'algorithme de chiffrement par défaut est l'algorithme du Standard de chiffrement des données (DES, Data Encryption Standard) en mode chaînage de blocs (CBC, cipher block chaining), comme décrit à la section 1.1 de la RFC 1423 [29], excepté que le remplissage à un multiple de 8 octets est indiqué comme décrit pour le bit P à la section 5.1. Le vecteur d'initialisation est zéro parce que des valeurs aléatoires sont fournies dans l'en-tête RTP ou par le préfixe aléatoire pour les paquets RTCP composés. Pour plus de détails sur l'usage des vecteurs d'initialisation CBC, voir [30].

Les implémentations qui prennent en charge la méthode de chiffrement spécifiée ici DEVRAIENT toujours prendre en charge l'algorithme DES en mode CBC comme chiffre par défaut pour cette méthode afin de maximiser l'interopérabilité. Cette méthode a été choisie parce qu'elle s'est révélée facile et pratique à utiliser dans les outils audio et vidéo expérimentaux en fonctionnement sur l'Internet. Toutefois, on a depuis découvert que DES est trop facilement brisé.

Il est RECOMMANDÉ que des algorithmes de chiffrement plus forts tels que le Triple-DES soient utilisés à la place de l'algorithme par défaut. En outre, le mode CBC sécurisé requiert que le premier bloc de chaque paquet soit XORé avec un IV aléatoire et indépendant de la même taille que la taille de bloc du chiffre. Pour RTCP, cela est (partiellement) accompli en préfixant chaque paquet d'un nombre aléatoire de 32 bits, choisi indépendamment pour chaque paquet. Pour RTP, l'horodatage et le numéro de séquence commencent à partir de valeurs aléatoires, mais les paquets consécutifs ne seront pas aléatoirement indépendants. Il doit être noté que l'aléatoire dans les deux cas (RTP et RTCP) est limité. Les applications à haute sécurité DEVRAIENT considérer d'autres moyens de protection plus conventionnels. D'autres algorithmes de chiffrement PEUVENT être spécifiés dynamiquement pour une session par des moyens non-RTP. En particulier, le profil SRTP [28] basé sur AES est en cours de développement pour prendre en compte les préoccupations de texte clair connu et de manipulation du texte clair CBC, et sera le bon choix dans le futur.

Comme alternative au chiffrement au niveau IP ou au niveau RTP comme décrit ci-dessus, les profils PEUVENT définir des types de charge utile supplémentaires pour les encodages chiffrés. Ces encodages DOIVENT spécifier comment le remplissage et d'autres aspects du chiffrement doivent être gérés. Cette méthode permet de chiffrer seulement les données tout en laissant les en-têtes en clair pour les applications où cela est désiré. Elle peut être particulièrement utile pour les dispositifs matériels qui géreront à la fois le déchiffrement et le décodage. Elle est aussi précieuse pour les applications où une compression de niveau liaison des en-têtes RTP et de couche inférieure est désirée et où la confidentialité de la charge utile (mais pas des adresses) est suffisante puisque le chiffrement des en-têtes empêche la compression.

9.2 Authentication and Message Integrity (Authentification et intégrité de message)​

Les services d'authentification et d'intégrité de message ne sont pas définis au niveau RTP puisque ces services ne seraient pas directement réalisables sans une infrastructure de gestion de clés. Il est attendu que les services d'authentification et d'intégrité seront fournis par les protocoles de couche inférieure.