Qu’est-ce que le SRTP ? Le protocole Secure Real-time Transport Protocol expliqué

Le SRTP (Secure Real-time Transport Protocol) est un profil de sécurité défini dans la RFC 3711 qui ajoute le chiffrement AES-128, l’authentification par HMAC-SHA1 et la protection contre le rejeu aux flux voix et vidéo RTP. Il utilise les mêmes ports UDP que le RTP standard (il n’existe pas de port SRTP dédié) et n’ajoute qu’environ 2 % de surcharge de bande passante avec un impact négligeable sur la latence, ce qui le rend adapté aux communications en temps réel.
Par défaut, les paquets RTP transmettent la voix et la vidéo sans chiffrement. Toute personne ayant accès au chemin réseau peut capturer ces paquets et reconstituer l’intégralité de la conversation. Le SRTP empêche cela en chiffrant chaque paquet de manière indépendante à l’aide du mode compteur AES et en l’authentifiant avec une empreinte HMAC avant la transmission.
Pour les opérateurs d’infrastructure VoIP, le SRTP n’est plus optionnel : le routage direct Microsoft Teams l’exige, le WebRTC le rend obligatoire, et les cadres de conformité tels que HIPAA et PCI DSS l’imposent pour le trafic vocal transportant des données sensibles. Ce guide explique ce que fait le SRTP, comment il fonctionne en détail, et quel rôle joue un contrôleur de session en périphérie (SBC) dans son déploiement sur les réseaux réels.

Pourquoi le chiffrement des médias VoIP est essentiel

Le RTP standard a été conçu pour l’efficacité, pas pour la sécurité. Il ne fournit ni chiffrement, ni vérification d’intégrité, ni protection contre les attaques par rejeu. En pratique, cela signifie :
L’écoute clandestine est le risque le plus direct. Un attaquant qui capture des paquets RTP sur un réseau partagé, un segment Wi-Fi ou une liaison d’infrastructure cloud peut décoder l’audio à l’aide d’outils librement disponibles comme Wireshark. Les données vocales sont directement accessibles dans la charge utile du paquet.
L’injection de paquets devient possible parce que le RTP n’a pas d’authentification. Un attaquant peut injecter des paquets fabriqués dans un flux RTP actif, et le terminal récepteur n’a aucun moyen de distinguer les paquets légitimes des paquets falsifiés.
Les attaques par rejeu surviennent lorsqu’un attaquant enregistre des paquets RTP et les retransmet ultérieurement, perturbant potentiellement les appels actifs ou rejouant des fragments de conversation sensibles.
Les attaques de l’homme du milieu (MitM) permettent à un attaquant positionné entre deux terminaux d’intercepter, de modifier ou de rediriger les flux RTP sans que l’une ou l’autre partie ne le sache. Sans chiffrement ni authentification, il n’existe aucun mécanisme permettant aux terminaux de vérifier que les paquets arrivent intacts de la source attendue.
Il ne s’agit pas de risques théoriques. Le trafic VoIP traverse régulièrement l’Internet public entre les fournisseurs de trunks SIP, les plateformes cloud et les terminaux distants. Chaque saut le long de ce chemin est un point d’exposition. Et à mesure que les organisations adoptent des modèles de travail hybrides et à distance, le trafic vocal traverse de plus en plus des réseaux que l’organisation ne contrôle pas.
Au-delà de l’hygiène sécuritaire, plusieurs exigences de conformité et de plateforme imposent désormais le chiffrement des médias :

• Le routage direct Microsoft Teams exige le SRTP pour tous les médias. Un SBC qui ne peut pas négocier le SRTP ne passera pas la certification Teams.
• WebRTC impose le DTLS-SRTP. Aucune plateforme de communication basée sur navigateur ne fonctionne sans.
• HIPAA exige le chiffrement des informations de santé protégées électroniquement (ePHI) en transit, ce qui inclut les communications vocales transportant des données patient.
• PCI DSS impose le chiffrement des données de cartes de paiement, y compris les numéros de carte communiqués oralement par VoIP.
• Les recommandations de la FCC font de plus en plus référence au chiffrement de la couche média dans le cadre des bonnes pratiques de sécurité des réseaux VoIP.

Comment fonctionne le SRTP

Le SRTP se superpose au RTP. Il prend un paquet RTP standard, chiffre la charge utile, ajoute une empreinte d’authentification et l’envoie sur le même transport UDP que le RTP. Le côté récepteur vérifie l’empreinte d’authentification, déchiffre la charge utile et transmet le média à l’application. Le processus n’ajoute qu’une latence minimale car le SRTP utilise des modes de chiffrement par flux conçus pour la tolérance au temps réel.

Chiffrement : AES en mode compteur

Le SRTP utilise l’Advanced Encryption Standard (AES) comme chiffrement par défaut. Plus précisément, il opère l’AES en mode compteur (AES-CM), qui transforme le chiffrement par blocs en chiffrement par flux. C’est un choix de conception délibéré pour les médias en temps réel.
Le mode compteur génère un flux de clés en chiffrant une séquence de valeurs de compteur. Le flux de clés est ensuite combiné bit à bit avec la charge utile en clair pour produire le texte chiffré. Comme chaque valeur de compteur est indépendante, le récepteur peut déchiffrer n’importe quel paquet sans avoir besoin d’avoir reçu tous les paquets précédents. Cela est essentiel pour la VoIP, où les paquets arrivent régulièrement dans le désordre ou sont perdus. Un mode de chiffrement nécessitant un déchiffrement séquentiel échouerait dans des conditions réseau normales.
Les deux suites cryptographiques standard définies pour le SRTP sont :

• AES_CM_128_HMAC_SHA1_80 (clé AES 128 bits, empreinte d’authentification 80 bits)
• AES_CM_128_HMAC_SHA1_32 (clé AES 128 bits, empreinte d’authentification 32 bits)

La variante 80 bits offre une authentification plus forte et constitue la configuration par défaut pour la plupart des déploiements.

Authentification des messages : HMAC-SHA1

Le chiffrement seul n’empêche pas la falsification. Un attaquant pourrait modifier des bits dans la charge utile chiffrée, et le récepteur la déchiffrerait en audio corrompu sans savoir que les données ont été modifiées.
Le SRTP résout ce problème avec HMAC-SHA1 (Hash-based Message Authentication Code utilisant SHA-1). Pour chaque paquet, le SRTP calcule un HMAC sur l’en-tête RTP et la charge utile chiffrée, puis tronque le résultat à 80 bits ou 32 bits. Cette empreinte d’authentification est ajoutée au paquet. Le récepteur recalcule le HMAC indépendamment et le compare. Si les empreintes ne correspondent pas, le paquet est rejeté.
Cela protège à la fois contre la modification et l’injection de paquets. Un attaquant ne peut pas forger une empreinte d’authentification valide sans la clé secrète.

Protection contre le rejeu

Le SRTP maintient une liste de rejeu (une fenêtre glissante des numéros de séquence des paquets récemment reçus). Si un paquet arrive avec un numéro de séquence déjà vu, ou un numéro qui se situe en dehors de la fenêtre acceptable, le paquet est rejeté. Cela empêche un attaquant d’enregistrer des paquets chiffrés et de les retransmettre pour perturber ou brouiller un appel.

Dérivation et échange de clés

Le SRTP utilise une fonction de dérivation de clés (KDF) pour générer plusieurs clés de session à partir d’une seule clé maître. La clé maître produit des clés de chiffrement, des clés d’authentification et des clés de salage distinctes pour le flux SRTP et son flux compagnon SRTCP (Secure RTCP). Cela signifie que le protocole de gestion des clés n’a besoin de fournir qu’une seule clé maître par session.
La clé maître elle-même est échangée lors de l’établissement de l’appel, via la couche de signalisation SIP. Deux mécanismes sont courants :
SDES (Session Description Protocol Security Descriptions) intègre la clé maître directement dans le corps SDP des messages SIP INVITE et 200 OK, dans un attribut crypto. C’est l’approche la plus simple, largement utilisée lorsque la signalisation SIP elle-même est chiffrée avec TLS. Sans TLS, le SDES expose la clé maître en clair dans la signalisation, ce qui annule l’intérêt du chiffrement.
DTLS-SRTP (Datagram Transport Layer Security for SRTP) effectue une négociation DTLS directement sur le chemin média pour établir les clés. Cette méthode est plus robuste car l’échange de clés ne dépend pas du chiffrement de la couche de signalisation. Le DTLS-SRTP est obligatoire pour le WebRTC et est de plus en plus adopté dans la VoIP d’entreprise.

SRTP vs RTP : qu’est-ce qui change ?

La surcharge de bande passante d’environ 2 % provient de l’empreinte d’authentification ajoutée à chaque paquet (4 à 10 octets selon la configuration) et du champ optionnel Master Key Identifier (MKI). Pour un appel G.711 utilisant une packetisation de 20 ms, cela représente environ 1,6 kbit/s de bande passante supplémentaire par direction. En pratique, c’est imperceptible.
Le SRTP a été spécifiquement conçu pour ajouter de la sécurité sans dégrader les performances en temps réel. Il réutilise le même transport UDP, les mêmes allocations de ports et la même structure d’en-tête RTP. L’infrastructure réseau qui achemine le trafic RTP acheminera le trafic SRTP de manière identique.

TLS + SRTP : une sécurité VoIP complète

Une idée fausse répandue est que le TLS sur la signalisation SIP suffit à sécuriser la VoIP. Ce n’est pas le cas. Un appel VoIP comporte deux flux de données distincts nécessitant chacun leur propre protection :
La signalisation (SIP) couvre les messages SIP qui établissent, modifient et terminent les appels. Ceux-ci contiennent les numéros appelé/appelant, les adresses IP, le SDP avec les informations de codec et de clé, et les métadonnées de routage. La signalisation SIP est chiffrée avec TLS (Transport Layer Security), généralement sur le port 5061.
Les médias (RTP/SRTP) sont les paquets voix ou vidéo réels. Ceux-ci sont chiffrés avec le SRTP sur des ports UDP négociés dynamiquement.
Si vous chiffrez la signalisation avec TLS mais laissez les médias en RTP, un attaquant ne peut pas voir qui a appelé qui, mais peut toujours capturer et écouter la conversation. Inversement, si vous chiffrez les médias avec le SRTP mais envoyez le SIP en clair, un attaquant peut voir l’échange de clés SDES et déchiffrer les médias.
Les deux couches doivent être chiffrées ensemble. Le TLS protège la signalisation. Le SRTP protège les médias. Et l’équipement qui applique les deux à la frontière du réseau est le contrôleur de session en périphérie.

Le rôle du SBC dans le SRTP

Dans la plupart des déploiements VoIP réels, le SBC se situe à la périphérie du réseau entre votre infrastructure vocale interne et les réseaux externes : fournisseurs de trunks SIP, Microsoft Teams, utilisateurs distants ou partenaires d’interconnexion. Le SBC est l’endroit où la politique de chiffrement est appliquée.
Un SBC fonctionnant comme Back-to-Back User Agent (B2BUA) termine et réinitie entièrement la signalisation et les médias de chaque côté de la connexion. Cette architecture lui confère trois capacités essentielles pour le déploiement du SRTP :

Relais SRTP

Lorsque les deux côtés d’un appel prennent en charge le SRTP, le SBC relaye les médias chiffrés entre eux. Le SBC négocie les paramètres cryptographiques (suite de chiffrement, clés) indépendamment sur chaque segment, déchiffre le SRTP entrant et le rechiffre pour le segment sortant. Cela maintient le chiffrement tout en permettant au SBC d’appliquer la politique média, d’effectuer la normalisation SIP et de générer les enregistrements détaillés des appels.

Conversion RTP vers SRTP

C’est là que le SBC devient indispensable pour les environnements mixtes. De nombreux IP-PBX existants, téléphones SIP anciens et certains fournisseurs de trunks SIP ne prennent en charge que le RTP. Les plateformes modernes comme Microsoft Teams et les applications WebRTC exigent le SRTP.
Le SBC comble cet écart en acceptant le RTP du côté existant, en le chiffrant en SRTP et en le transmettant à la destination exigeant le SRTP. Sur le chemin retour, le SBC déchiffre le SRTP en RTP pour le terminal existant. L’équipement ancien n’a jamais besoin de changer.
Cette conversion RTP vers SRTP est ce qui permet aux organisations de connecter l’infrastructure vocale existante au routage direct Teams, aux centres de contact cloud et aux autres plateformes qui imposent le chiffrement, sans remplacer le matériel ni reformer le personnel.

Masquage de topologie avec contexte de chiffrement

Le SBC masque les adresses IP du réseau interne aux parties externes. Combiné au SRTP, cela signifie que les entités externes ne voient ni la topologie du réseau interne ni le contenu des médias. Le SBC présente ses propres adresses IP au monde extérieur et gère des contextes cryptographiques SRTP distincts pour chaque segment de l’appel.

Quand avez-vous besoin du SRTP ?

La réponse courte : toujours, lorsque c’est possible. Le chiffrement des médias a un coût de performance négligeable et un bénéfice sécuritaire significatif. Mais certains scénarios le rendent obligatoire plutôt que recommandé.
Le routage direct Microsoft Teams exige le SRTP pour tous les médias. Si votre SBC ne prend pas en charge la négociation SRTP et la conversion RTP vers SRTP, les appels Teams échoueront.
Les applications WebRTC utilisent toutes le DTLS-SRTP. Si vous intégrez des communications basées sur navigateur à votre réseau vocal, le SRTP n’est pas optionnel.
Le secteur de la santé (HIPAA) traite les appels vocaux transportant des informations patient comme des ePHI en transit. Le SRTP fournit la couche de chiffrement nécessaire pour répondre aux exigences de sécurité de transmission de la règle de sécurité HIPAA.
Les services financiers (PCI DSS) imposent le chiffrement des données de cartes de paiement, y compris les numéros de carte communiqués oralement par VoIP. Le SRTP protège le segment média.
Les travailleurs à distance et hybrides représentent un point d’exposition croissant. Lorsque le trafic VoIP quitte le réseau d’entreprise et traverse l’Internet public pour atteindre les employés distants, le chiffrement empêche l’interception sur des segments réseau non contrôlés. Les SBC avec prise en charge SIP/TLS et SRTP protègent ces connexions à la périphérie d’accès.
Tout trafic traversant l’Internet public devrait être chiffré. Si les paquets vocaux traversent un segment réseau que vous ne contrôlez pas physiquement, le chiffrement est une mesure de sécurité de base.

Idées reçues sur le SRTP

Le SRTP remplace le TLS est une supposition courante, mais incorrecte. Le SRTP chiffre les médias. Le TLS chiffre la signalisation. Ils protègent des flux de données différents et les deux sont nécessaires pour une sécurité VoIP complète. Sans TLS, l’échange de clés SDES dans la signalisation SIP expose la clé maître SRTP en clair.
Le SRTP ajoute une latence significative est une autre idée fausse. Le mode compteur AES est un chiffrement par flux qui traite chaque paquet indépendamment sans nécessiter de retour des paquets précédents. Les études montrent environ 2 % de surcharge de bande passante avec un impact négligeable sur la latence. Il n’y a pas de dégradation perceptible de la qualité.
Tous les équipements VoIP prennent en charge le SRTP n’est pas le cas. De nombreux IP-PBX existants, adaptateurs téléphoniques analogiques et téléphones SIP anciens ne prennent en charge que le RTP. Un SBC avec une capacité de conversion RTP vers SRTP comble cet écart sans nécessiter de remplacement d’équipement.
Le SRTP fournit un chiffrement de bout en bout est techniquement possible mais peu courant. Dans la plupart des déploiements d’entreprise, le SRTP fonctionne saut par saut. Le SBC déchiffre et rechiffre les médias à la frontière du réseau. Cela permet au SBC d’appliquer la politique de sécurité, de générer les CDR et d’effectuer des opérations sur les médias. Le véritable chiffrement de bout en bout (où seuls les deux terminaux détiennent les clés) est rare dans la VoIP de production car il empêche tout traitement intermédiaire.

Premiers pas avec le SRTP

Le déploiement du SRTP sur votre réseau VoIP se fait en quatre étapes :

1. Auditez votre état actuel de chiffrementIdentifiez quels trunks, terminaux et plateformes utilisent actuellement le RTP plutôt que le SRTP. Notez quelles connexions traversent l’Internet public et lesquelles restent dans votre réseau contrôlé. Priorisez les connexions exposées à Internet et celles soumises à des exigences de conformité.
2. Activez le TLS sur la signalisation SIPL’échange de clés SRTP via SDES dépend du TLS pour protéger la clé maître en transit. Configurez le TLS sur votre SBC pour toutes les connexions SIP, en commençant par les trunks exposés à Internet. Utilisez le port 5061 (le port standard SIP sur TLS).
3. Configurez le SRTP sur votre SBCActivez le SRTP pour chaque groupe de trunks ou point d’accès réseau. Pour les environnements mixtes, configurez le SBC pour effectuer la conversion RTP vers SRTP afin que les terminaux existants puissent se connecter aux plateformes exigeant le SRTP sans modification.
4. Vérifiez avec une capture de paquetsUtilisez Wireshark ou les outils de capture intégrés de votre SBC pour confirmer que les paquets média sur les trunks compatibles SRTP sont chiffrés. Vérifiez que la conversion RTP vers SRTP fonctionne correctement sur les segments mixtes. Confirmez que le SRTCP est également chiffré parallèlement au SRTP.

Le SRTP dans la pile de sécurité VoIP

Le SRTP est une couche dans une approche de défense en profondeur de la sécurité VoIP. Un réseau vocal renforcé combine :

• SRTP pour le chiffrement des médias
• TLS pour le chiffrement de la signalisation
• SBC avec architecture B2BUA pour le masquage de topologie, le contrôle d’accès et l’application du chiffrement
• Protection DoS/DDoS au niveau du SBC pour atténuer les attaques par inondation SIP
• Liste noire dynamique et listes de contrôle d’accès aux appels pour bloquer le trafic malveillant
• STIR/SHAKEN pour l’authentification de l’identité de l’appelant

Chaque couche couvre un vecteur de menace différent. Le SRTP traite spécifiquement la confidentialité et l’intégrité des médias voix et vidéo en transit. Combiné aux autres couches, il fait partie d’une posture de sécurité VoIP complète.

Foire aux questions

Conclusion

Le SRTP étend le RTP avec le chiffrement AES, l’authentification HMAC-SHA1 et la protection contre le rejeu. Il n’ajoute qu’environ 2 % de surcharge de bande passante avec un impact négligeable sur la latence. Le TLS et le SRTP fournissent ensemble une sécurité VoIP complète : le TLS pour la signalisation, le SRTP pour les médias.
Le SBC est le point d’application. Il négocie les paramètres SRTP, convertit le RTP en SRTP pour les terminaux existants et maintient des contextes de chiffrement distincts sur chaque segment d’appel. Pour les organisations se connectant à Microsoft Teams, aux plateformes WebRTC ou à tout service exigeant le SRTP, un SBC avec capacité de conversion RTP vers SRTP est le pont entre l’infrastructure existante et les exigences de sécurité modernes.