Explication SRTP

Le protocole de transport en temps réel sécurisé (SRTP) est un système de sécurité qui étend le protocole de transport en temps réel (RTP) avec un ensemble de mécanismes de sécurité.

WebRTC utilise DTLS-SRTP pour le chiffrement, l'authentification et l'intégrité des messages, ainsi que la protection contre les attaques par relecture. Cela garantit la confidentialité grâce au chiffrement et à l'authentification de la charge RTP. SRTP est l'un des composants de la sécurité, il est très pratique pour les développeurs qui recherchent une API fiable et sécurisée. Mais qu'est-ce que SRTP et comment ça marche?

Qu'est-ce que SRTP?

SRTP améliore la sécurité RTP. Le protocole a été publié par l'IETF (Internet Engineering Task Force) dans la RFC 3711 , en mars 2004.

SRTP assure la confidentialité en chiffrant la charge RTP, sans inclure les en-têtes RTP. L'authentification est également prise en charge, qui est largement utilisée comme mécanisme de sécurité dans RTP. Bien que SRTP puisse être utilisé dans son intégralité, il est également possible de désactiver / activer certaines fonctions. Le plugin principal de SRTP est la gestion des clés, car il existe de nombreuses options: DTLS-SRTP, MIKEY en SIP, SDES (Security Description) en SDP, ZRTP, etc.

Cryptage

SRTP utilise AES (Advanced Encryption Standard) comme chiffre par défaut. AES a deux modes de cryptage: le mode compteur de segments segmentés et le mode f8. Le mode compteur est généralement utilisé - il est extrêmement important lors de la transmission de trafic sur un réseau non fiable avec une perte potentielle de paquets. Le mode f8 est utilisé dans les réseaux mobiles 3G et est une variante du mode Feedback de sortie, dans lequel le déchiffrement se produit de la même manière que le chiffrement.

SRTP permet également aux développeurs de désactiver le chiffrement à l'aide d'un chiffrement nul. Le chiffrement zéro ne fait pas de chiffrement; il copie le flux entrant directement dans le flux sortant, sans modifications.

WebRTC ne recommande pas l'utilisation d'un chiffre zéro, car la sécurité des données est très importante pour les utilisateurs finaux. En fait, les implémentations WebRTC valides DOIVENT prendre en charge le chiffrement, actuellement avec DTLS-SRTP .

Intégrité

Pour préserver l'intégrité des messages dans SRTP, une étiquette d'authentification est créée en fonction du contenu et d'une partie des en-têtes de paquet, qui est ensuite ajoutée au paquet RTP. Cette étiquette est utilisée pour valider le contenu de la charge utile, ce qui empêche la falsification des données.

L'authentification est également la base pour repousser les attaques de ré-accès. Pour les bloquer, un index séquentiel est attribué à chaque paquet. Un nouveau message ne sera accepté que si son index est le suivant dans l'ordre et n'a pas encore été reçu. Les indices sont efficaces en raison de l'intégrité décrite ci-dessus; sans elle, il y a la possibilité d'une substitution d'indices.

Bien que WebRTC utilise principalement l'algorithme HMAC-SHA1 pour l'intégrité SRTP, il est fortement recommandé de sélectionner des ensembles d'algorithmes avec PFS (Perfect Forward Secrecy) sur non-PFS et AEAD (Authenticated Encryption with Associated Data) sur non-AEAD. Les implémentations WebRTC récentes utilisent DTLS v1.2 avec la suite d'algorithmes TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.

Les clés

SRTP utilise la fonction de génération de clés (KDF) pour créer des clés basées sur la clé principale. Le protocole de gestion des clés crée toutes les clés d'une session à l'aide d'une clé principale. Étant donné que chaque session a sa propre clé unique, toutes les sessions sont protégées. Par conséquent, si une session a été compromise, le reste est toujours protégé. Le protocole de gestion des clés est utilisé pour la clé principale - il s'agit généralement de ZRTP ou MIKEY, mais il existe d'autres variantes.


Pile IP RTP

Les flux dans WebRTC sont protégés par l'un des deux protocoles: SRTP ou DTLS (Datagram Transport Layer Security). DTLS - pour le chiffrement des flux de données, SRTP - pour les flux multimédias. Cependant, pour l'échange de clés dans SRTP, DTLS-SRTP est utilisé pour détecter les attaques de courtier. Ceci est détaillé dans les documents de l'IETF: WebRTC security and security arch .

SRTCP (Secure Real-time Transport Control Protocol)

SRTP a un protocole frère - SRTCP (Secure Real-time Transport Control Protocol). SRTCP étend RTCP (Real-time Transport Control Protocol) avec les mêmes fonctionnalités que SRTP étend RTP, y compris le chiffrement et l'authentification. Comme SRTP, presque toutes les fonctionnalités de sécurité SRTCP peuvent être désactivées, à l'exception de l'authentification des messages - elle est nécessaire pour SRTCP.

Pièges de SRTP

SRTP crypte la charge utile des paquets RTP, mais pas l'extension d'en-tête. Cela crée une vulnérabilité car l'extension d'en-tête dans le paquet RTP peut contenir des informations importantes, par exemple, les niveaux sonores de chaque paquet dans le flux multimédia. Potentiellement, un attaquant peut savoir que deux personnes communiquent sur le réseau - la confidentialité de la conversation peut être compromise. Cela a été discuté dans la demande de commentaires IETF : 6904 , qui nécessite toutes les implémentations ultérieures de SRTP pour chiffrer les extensions d'en-tête.

Dans certains cas - par exemple, une conférence avec de nombreux participants - un intermédiaire sous forme de SFM (Selective Forwarding Mixer) peut être nécessaire afin d'optimiser les paramètres RTP lors de la transmission de flux. Un tel intermédiaire viole le principe de chiffrement de bout en bout utilisé dans les systèmes peer-to-peer; en d'autres termes, les terminaux doivent «faire confiance» à un autre participant. Pour contourner cette limitation, la conférence Enhanced RTP Conferencing (PERC, l'un des groupes de travail de l'IETF) travaille sur des solutions telles que les procédures de double cryptage de SRTP . Les PERC fournissent des garanties soutenues par un chiffrement bond par bond et de bout en bout dans deux contextes distincts mais liés. Nous vous en parlerons dans les prochains articles!