Introduction à libSRTP

Ce paquet fournit une implémentation du protocole de transport temps réel sécurisé (SRTP), de la transformation de sécurité universelle (UST), ainsi qu'un noyau cryptographique de support. L'API SRTP est documentée dans include/srtp.h, et la bibliothèque se trouve dans libsrtp2.a (après compilation).

Ce document décrit libSRTP, la bibliothèque RTP sécurisée Open Source de Cisco Systems, Inc. RTP est le protocole de transport temps réel, une norme IETF pour le transport de données temps réel telles que la téléphonie, l'audio et la vidéo, définie par RFC 3550. Le RTP sécurisé (SRTP) est un profil RTP visant à assurer la confidentialité des données RTP et l'authentification de l'en-tête et de la charge utile RTP. SRTP est une norme IETF, définie dans RFC 3711, et a été développé au sein du groupe de travail Audio/Video Transport (AVT) de l'IETF. Cette bibliothèque prend en charge toutes les fonctionnalités obligatoires de SRTP, mais pas toutes les fonctionnalités optionnelles. Voir la section Fonctionnalités prises en charge pour plus de détails.

Ce document sert également à générer les fichiers de documentation dans le dossier /doc/, où une référence plus détaillée de l'API libSRTP et des fonctions associées peut être créée (nécessite l'installation de doxygen). Le matériel de référence est créé automatiquement à partir de commentaires intégrés dans certains des fichiers d'en-tête C. La documentation est organisée en modules afin d'en améliorer la clarté. Ces modules ne correspondent pas directement aux fichiers. Un noyau cryptographique sous-jacent fournit l'essentiel des fonctionnalités de base de libSRTP mais est en grande partie non documenté, car il opère en arrière-plan.

Nous contacter

• [email protected] liste de diffusion générale pour les actualités / annonces / discussions. Cette liste est ouverte, voir https://lists.packetizer.com/mailman/listinfo/libsrtp pour vous y inscrire.

• [email protected] pour divulguer des problèmes de sécurité à l'équipe de maintenance de libsrtp. Cette liste est fermée, mais toute personne peut y envoyer des messages.

Sommaire

• Introduction à libSRTP
• Nous contacter
  • Sommaire
• Licence et avertissement
• Vue d'ensemble de libSRTP
  • Contexte du RTP sécurisé
  • Fonctionnalités prises en charge
  • Notes d'implémentation
• Installation et compilation de libSRTP
  • Modification de la configuration de compilation
  • Utilisation de Visual Studio
• Applications
  • Exemple de code
• Crédits
• Références

Licence et avertissement

libSRTP est distribué sous la licence suivante, qui est incluse dans la distribution du code source. Elle est reproduite dans le manuel au cas où vous auriez obtenu la bibliothèque d'une autre source.

Copyright (c) 2001-2017 Cisco Systems, Inc. Tous droits réservés.

La redistribution et l'utilisation sous forme source et binaire, avec ou sans modification, sont autorisées à condition que les conditions suivantes soient remplies :

• Les redistributions du code source doivent conserver l'avis de copyright ci-dessus, cette liste de conditions et l'avertissement suivant.
• Les redistributions sous forme binaire doivent reproduire l'avis de copyright ci-dessus, cette liste de conditions et l'avertissement suivant dans la documentation et/ou les autres matériels fournis avec la distribution.
• Ni le nom de Cisco Systems, Inc. ni les noms de ses contributeurs ne peuvent être utilisés pour approuver ou promouvoir des produits dérivés de ce logiciel sans autorisation écrite préalable spécifique.

CE LOGICIEL EST FOURNI PAR LES DÉTENTEURS DU COPYRIGHT ET LES CONTRIBUTEURS « TELLE QUEL » ET TOUTE GARANTIE EXPRESSE OU IMPLICITE, Y COMPRIS, MAIS SANS S'Y LIMITER, LES GARANTIES IMPLICITES DE QUALITÉ MARCHANDE ET D'ADÉQUATION À UN USAGE PARTICULIER SONT DÉCLINÉES. EN AUCUN CAS LES DÉTENTEURS DU COPYRIGHT OU LES CONTRIBUTEURS NE POURRONT ÊTRE TENUS RESPONSABLES DE TOUT DOMMAGE DIRECT, INDIRECT, ACCESSOIRE, SPÉCIAL, EXEMPLAIRE OU CONSÉCUTIF (Y COMPRIS, MAIS SANS S'Y LIMITER, L'ACHAT DE BIENS OU DE SERVICES DE SUBSTITUTION ; LA PERTE D'UTILISATION, DE DONNÉES OU DE PROFITS ; OU UNE INTERRUPTION D'ACTIVITÉ) QUELLE QU'EN SOIT LA CAUSE ET SUR TOUTE THÉORIE DE RESPONSABILITÉ, QUE CE SOIT EN CONTRAT, EN RESPONSABILITÉ STRICTE, OU EN DÉLIT (Y COMPRIS LA NÉGLIGENCE OU AUTREMENT) DÉCOULANT DE QUELQUE MANIÈRE QUE CE SOIT DE L'UTILISATION DE CE LOGICIEL, MÊME SI LA POSSIBILITÉ DE TELS DOMMAGES A ÉTÉ SIGNALÉE.

Vue d'ensemble de libSRTP

libSRTP fournit des fonctions pour protéger RTP et RTCP. Les paquets RTP peuvent être chiffrés et authentifiés (à l'aide de la fonction srtp_protect()), ce qui les transforme en paquets SRTP. De même, les paquets SRTP peuvent être déchiffrés et leur authentification vérifiée (à l'aide de la fonction srtp_unprotect()), ce qui les transforme en paquets RTP. Des fonctions similaires appliquent la sécurité aux paquets RTCP.

Le typedef srtp_stream_t pointe vers une structure contenant tout l'état associé à un flux SRTP, y compris les clés et les paramètres des fonctions de chiffrement et d'authentification des messages, ainsi que les données anti-rejeu. Un srtp_stream_t particulier contient les informations nécessaires pour protéger un flux RTP et RTCP spécifique. Ce type de données est volontairement opaque afin de mieux séparer l'API libSRTP de son implémentation.

Au sein d'une session SRTP, il peut y avoir plusieurs flux, chacun provenant d'un émetteur particulier. Chaque source utilise un contexte de flux distinct pour protéger le flux RTP et RTCP qu'elle émet. Le typedef srtp_t pointe vers une structure contenant tout l'état associé à une session SRTP. Plusieurs contextes de flux peuvent être associés à un seul srtp_t. Un contexte de flux ne peut pas exister indépendamment d'un srtp_t, bien qu'un srtp_t puisse bien sûr être créé avec un seul contexte de flux. Un appareil participant à une session SRTP doit disposer d'un contexte de flux pour chaque source de cette session, afin de pouvoir traiter les données qu'il reçoit de chaque émetteur.

Dans libSRTP, une session est créée à l'aide de la fonction srtp_create(). La politique à mettre en œuvre dans la session est passée à cette fonction sous la forme d'un handle opaque srtp_policy_t. Un seul handle de politique décrit une politique de flux. Pour configurer plusieurs flux, créez une session et ajoutez des politiques supplémentaires avec srtp_stream_add().

Un handle de politique est configuré avec les fonctions srtp_policy_set_*. Au minimum, cela inclut la sélection du SSRC, la sélection du profil et le matériel de clé/sel. Le profil configure les paramètres de politique cryptographique RTP/RTCP, tandis que le sélecteur SSRC identifie comment et où cette politique est appliquée.

Contexte du RTP sécurisé

Dans cette section, nous passons en revue SRTP et introduisons certains termes utilisés dans libSRTP. Une session RTP est définie par une paire d'adresses de transport de destination, c'est-à-dire une adresse réseau plus une paire de ports UDP pour RTP et RTCP. RTCP, le protocole de contrôle RTP, est utilisé pour coordonner les participants d'une session RTP, par exemple pour fournir un retour des récepteurs aux émetteurs. Une session SRTP est définie de la même manière ; il s'agit simplement d'une session RTP pour laquelle le profil SRTP est utilisé. Une session SRTP comprend le trafic envoyé aux adresses de transport de destination SRTP ou SRTCP. Chaque participant à une session est identifié par un identifiant de source de synchronisation (SSRC). Certains participants peuvent ne pas envoyer de trafic SRTP ; ils sont appelés récepteurs, même s'ils envoient du trafic SRTCP, comme des rapports de récepteur.

RTP permet à plusieurs sources d'envoyer du trafic RTP et RTCP au cours de la même session. L'identifiant de source de synchronisation (SSRC) est utilisé pour distinguer ces sources. Dans libSRTP, nous appelons le trafic SRTP et SRTCP d'une source particulière un flux. Chaque flux possède son propre SSRC, numéro de séquence, compteur de rollover et autres données. Un choix particulier d'options, de mécanismes cryptographiques et de clés est appelé une politique. Chaque flux d'une session peut avoir une politique distincte qui lui est appliquée.

Une seule politique peut être utilisée pour tous les flux d'une session donnée, bien que le cas où une seule clé est partagée entre plusieurs flux nécessite de la prudence. Lorsque le partage de clé est utilisé, les valeurs SSRC qui identifient les flux doivent être distinctes. Cette exigence peut être appliquée en utilisant la convention selon laquelle chaque clé SRTP et SRTCP n'est utilisée pour le chiffrement que par un seul émetteur. En d'autres termes, la clé n'est partagée qu'entre les flux provenant d'un appareil particulier (bien entendu, les autres participants SRTP devront utiliser la clé pour le déchiffrement). libSRTP prend en charge cette application en détectant le cas où une clé est utilisée à la fois pour les données entrantes et sortantes.

Fonctionnalités prises en charge

Cette bibliothèque prend en charge toutes les fonctionnalités obligatoires de SRTP (telles que définies dans RFC 3711). Certaines de ces fonctionnalités peuvent être sélectionnées (ou désélectionnées) au moment de l'exécution en définissant une politique appropriée à l'aide d'un handle srtp_policy_t. Certains autres comportements du protocole peuvent être adaptés en définissant un gestionnaire d'événements approprié pour les événements exceptionnels ; voir la section SRTPevents dans la documentation générée.

Certaines options décrites dans la spécification SRTP ne sont pas prises en charge. Cela inclut

• les taux de dérivation de clé différents de zéro,
• le chiffrement F8,
• l'utilisation de l'index de paquet pour sélectionner entre les clés maîtresses.

L'utilisateur doit être conscient qu'il est possible de faire un mauvais usage de cette bibliothèque et que le résultat peut être un niveau de sécurité inadéquat. Si vous implémentez une fonctionnalité à l'aide de cette bibliothèque, vous voudrez lire la section Security Considerations de RFC 3711. De plus, il est important de lire et de comprendre les conditions énoncées dans la section Licence et avertissement.

Cette bibliothèque prend également en charge les méthodes de chiffrement authentifié AES-GCM décrites dans RFC 7714

Notes d'implémentation

• Il est possible de configurer le backend cryptographique tiers (openssl/nss/etc) avec lequel libSRTP sera compilé. Si aucun backend tiers n'est défini, libSRTP fournit une implémentation interne d'AES et de Sha1. L'implémentation interne ne prend en charge que AES-128 et AES-256 ; pour utiliser AES-192 ou le groupe de chiffrements AES-GCM, un backend cryptographique tiers doit être configuré. Pour cette raison et pour des raisons de performance, il est fortement recommandé d'utiliser un backend cryptographique tiers.

• La fonction srtp_protect() suppose que le tampon contenant le paquet rtp dispose de suffisamment de stockage alloué pour que l'étiquette d'authentification puisse être écrite à la fin de ce paquet. Si cette hypothèse n'est pas valide, une corruption de mémoire s'ensuivra.

• Des tests automatisés pour les fonctions cryptographiques sont fournis via les fonctions cipher_type_self_test() et auth_type_self_test(). Ces fonctions doivent être utilisées pour tester chaque portage de ce code vers une nouvelle plateforme.

• La protection anti-rejeu est contenue dans le moteur cryptographique, et des tests sont fournis pour celle-ci.

• Cette implémentation fournit des appels pour initialiser, protéger et déprotéger les paquets RTP, et fait aussi peu d'hypothèses que possible sur la manière dont ces fonctions seront appelées. Par exemple, l'appelant n'est pas tenu de fournir les paquets dans l'ordre (bien que s'ils sont appelés plus de 65 000 hors séquence, la synchronisation sera perdue).

• Le numéro de séquence dans le paquet rtp est utilisé comme les 16 bits de poids faible de l'index de paquet local de l'émetteur. Notez que RTP commencera son numéro de séquence à un endroit aléatoire, et que la couche SRTP saute simplement jusqu'à ce numéro lors de sa première invocation. Une version antérieure de cette bibliothèque utilisait des numéros de séquence initiaux inférieurs à 32 768 ; cette astuce n'est plus nécessaire car la fonction rdbx_estimate_index(...) est devenue plus intelligente depuis la version 1.0.1.

• La fenêtre anti-rejeu pour (S)RTCP est codée en dur sur une longueur de 128 bits.

Installation et compilation de libSRTP

Pour installer libSRTP, téléchargez la dernière version de la distribution depuis https://github.com/cisco/libsrtp/releases. Vous voudrez probablement obtenir la version la plus récente. Décompressez la distribution et extrayez les fichiers source ; le répertoire dans lequel les fichiers source seront placés s'appelle libsrtp-A-B-C, où A est le numéro de version, B le numéro de version majeure et C le numéro de version mineure.

libSRTP utilise les utilitaires GNU autoconf et make (le make BSD ne fonctionnera pas ; si les deux versions de make sont présentes sur votre plateforme, vous pouvez invoquer GNU make comme gmake). Dans le répertoire libsrtp, exécutez le script configure puis make :~~~.txt ./configure [ options ] make

Le script configure accepte les options suivantes :

Option                         | Description
-------------------------------|--------------------
\-\-help                   \-h | Afficher l'aide
\-\-enable-debug-logging       | Activer la journalisation de débogage dans tous les modules
\-\-enable-openssl             | Activer le moteur cryptographique OpenSSL
\-\-enable-nss                 | Activer le moteur cryptographique NSS
\-\-enable-openssl-kdf         | Activer l'algorithme KDF d'OpenSSL
\-\-enable-log-stdout          | Activer la journalisation vers stdout
\-\-with-openssl-dir           | Emplacement de l'installation d'OpenSSL
\-\-with-nss-dir               | Emplacement de l'installation de NSS
\-\-with-log-file              | Utiliser un fichier pour la journalisation

Par défaut, aucune journalisation n'est émise ; la journalisation peut être activée pour être envoyée vers stdout
ou vers un fichier donné à l'aide des options de configuration.

Ce paquet a été testé sur les plateformes suivantes : Mac OS X
(powerpc-apple-darwin1.4), Cygwin (i686-pc-cygwin), Solaris
(sparc-sun-solaris2.6), RedHat Linux 7.1 et 9 (i686-pc-linux), et
OpenBSD (sparc-unknown-openbsd2.7).

--------------------------------------------------------------------------------

<a name="changing-build-configuration"></a>
## Modification de la configuration de compilation

Pour construire le script `./configure` mentionné ci-dessus, libSRTP repose sur la
chaîne d'outils [automake](https://www.gnu.org/software/automake/).  Comme
`./configure` est généré à partir de `configure.in` par automake, si vous modifiez la
manière dont `./configure` fonctionne (par exemple, pour ajouter une nouvelle dépendance de bibliothèque), vous devrez
reconstruire `./configure` et valider la version mise à jour.  En plus
d'automake lui-même, vous devrez également avoir les outils `pkgconfig` installés.

Par exemple, sur macOS :```
brew install automake pkgconfig
# Edit configure.in
autoremake -ivf
```
<a name="using-visual-studio"></a>
## Utilisation de Visual Studio

Sous Windows, on peut utiliser Visual Studio via CMake. CMake peut être téléchargé ici :
https://cmake.org/ . Pour créer des fichiers de build Visual Studio, par exemple exécutez les
commandes suivantes :```
# Create build subdirectory
mkdir build
cd build

# Make project files
cmake .. -G "Visual Studio 15 2017"

# Or for 64 bit project files
cmake .. -G "Visual Studio 15 2017 Win64"
```
<a name="using-meson"></a>
## Utilisation de Meson

Sur toutes les plateformes, y compris Windows, on peut compiler avec [Meson](https://mesonbuild.com).
Les étapes pour télécharger Meson se trouvent ici : https://mesonbuild.com/Getting-meson.html

Pour compiler avec Meson, vous pouvez faire quelque chose comme :```
# Setup the build subdirectory
meson setup --prefix=/path/to/prefix builddir

# Build the project
meson compile -C builddir

# Run tests
meson test -C builddir

# Optionally, install
meson install -C builddir
```
Pour compiler avec Visual Studio, exécutez les commandes ci-dessus depuis une invite de commandes Visual Studio, ou exécutez `vcvarsall.bat` avec les arguments appropriés dans une invite de commandes.

Notez que vous pouvez également remplacer les commandes ci-dessus par les cibles `ninja` appropriées : `ninja -C build`, `ninja -C build test`, `ninja -C build install`.

--------------------------------------------------------------------------------

<a name="applications"></a>
# Applications

Plusieurs pilotes de test et une application srtp simple et portable sont
inclus dans le sous-répertoire `test/`.

Test driver     | Fonction testée
---------       | -------
kernel_driver   | noyau crypto (chiffrements, fonctions d'authentification, rng)
srtp_driver	    | tests srtp en mémoire (n'utilise pas le réseau)
rdbx_driver	    | rdbx (base de rejeu étendue)
roc_driver	    | fonctions de numéros de séquence étendues
replay_driver	  | base de rejeu
cipher_driver	  | chiffrements
auth_driver	    | fonctions de hachage

L'application `rtpw` est une application rtp simple qui lit des mots depuis
`/usr/dict/words` puis les envoie un par un en utilisant [s]rtp.
La gestion manuelle des clés srtp utilise l'option -k ; la gestion automatisée
des clés via gdoi sera ajoutée ultérieurement.

Utilisation :~~~.txt
rtpw [[-d <debug>]* [-k|b <key> [-a][-e <key size>][-g]] [-s | -r] dest_ip dest_port] | [-l]

L'option -s (émetteur) ou -r (récepteur) doit être choisie. Les valeurs dest_ip, dest_port sont respectivement l'adresse IP et le port UDP vers lesquels le dictionnaire sera envoyé.

Les options sont :

Afin d'obtenir des valeurs aléatoires de 30 octets à utiliser comme paires clé/sel, vous pouvez utiliser la fonction bash suivante pour formater la sortie de /dev/random (là où ce périphérique est disponible).~~~.txt function randhex() { cat /dev/random | od --read-bytes=32 --width=32 -x | awk '{ print $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13 $14 $15 $16 }' }

Un exemple de session SRTP utilisant deux programmes rtpw suit :~~~.txt
set k=c1eec3717da76195bb878578790af71c4ee9f859e197a414a78d5abc7451

[sh1]$ test/rtpw -s -k $k -e 128 -a 0.0.0.0 9999
Security services: confidentiality message authentication
set master key/salt to C1EEC3717DA76195BB878578790AF71C/4EE9F859E197A414A78D5ABC7451
setting SSRC to 2078917053
sending word: A
sending word: a
sending word: aa
sending word: aal
...

[sh2]$ test/rtpw -r -k $k -e 128 -a 0.0.0.0 9999
security services: confidentiality message authentication
set master key/salt to C1EEC3717DA76195BB878578790AF71C/4EE9F859E197A414A78D5ABC7451
19 octets received from SSRC 2078917053 word: A
19 octets received from SSRC 2078917053 word: a
20 octets received from SSRC 2078917053 word: aa
21 octets received from SSRC 2078917053 word: aal
...

Code d'exemple

Cette section fournit un exemple simple d'utilisation de libSRTP. Nous supposons ici que les fonctions get_rtp_packet() et send_srtp_packet() sont disponibles pour nous. La première place un paquet RTP dans le tampon et renvoie le nombre d'octets écrits dans ce tampon. La seconde envoie le paquet RTP contenu dans le tampon, en prenant la longueur comme deuxième argument.~~~.c srtp_t session; srtp_policy_t policy;

// Set key/salt to predetermined values. uint8_t master_key[16] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}; uint8_t master_salt[14] = {0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D};

// Initialize libSRTP. srtp_init();

// Create and configure an opaque policy handle. srtp_policy_create(&policy); srtp_policy_set_ssrc(policy, (srtp_ssrc_t){ssrc_any_outbound, 0}); srtp_policy_set_profile(policy, srtp_profile_aes128_cm_sha1_80); srtp_policy_add_key(policy, master_key, sizeof(master_key), master_salt, sizeof(master_salt), NULL, 0);

// Allocate and initialize the SRTP session. srtp_create(&session, policy);

srtp_policy_destroy(policy);

// Main loop: get RTP packets, send SRTP packets. while (1) { char rtp_buffer[2048]; size_t rtp_len; char srtp_buffer[2048]; size_t srtp_len = sizeof(srtp_buffer);

rtp_len = get_rtp_packet(rtp_buffer); srtp_protect(session, rtp_buffer, rtp_len, srtp_buffer, &srtp_len); send_srtp_packet(srtp_buffer, srtp_len); }

srtp_dealloc(session); srtp_shutdown();

<a name="credits"></a>
# Crédits

L'implémentation originale et la documentation de libSRTP ont été écrites
par David McGrew de Cisco Systems, Inc. afin de promouvoir l'utilisation,
la compréhension et l'interopérabilité de Secure RTP. Michael Jerris
a contribué au support de compilation sous MSVC. Andris Pavenis
a apporté de nombreuses corrections importantes. Brian West a contribué aux changements permettant
la liaison dynamique. Yves Shumann a signalé des erreurs de documentation.
Randell Jesup a contribué à une implémentation SRTCP fonctionnelle et à d'autres
corrections. Steve Underwood a contribué aux modifications de portabilité x86_64. Nous remercions également
Fredrik Thulin, Brian Weis, Mark Baugher, Jeff Chan, Bill
Simon, Douglas Smith, Bill May, Richard Preistley, Joe Tardo et
d'autres pour leurs contributions, commentaires et corrections.

Ce document de référence, lorsqu'il est applicable, a été généré
à l'aide de l'utilitaire doxygen pour la documentation automatique du code source.

Copyright 2001-2005 par David A. McGrew, Cisco Systems, Inc.

--------------------------------------------------------------------------------

<a name="references"></a>
# Références

Références SRTP et ICM
Septembre 2005

Secure RTP est défini dans [RFC 3711](https://tools.ietf.org/html/rfc3711).
La définition du mode compteur se trouve dans la [Section 4.1.1](https://tools.ietf.org/html/rfc3711#section-4.1.1).

SHA-1 est défini dans [FIPS PUB 180-4](http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf).

HMAC est défini dans [RFC 2104](https://tools.ietf.org/html/rfc2104)
et les vecteurs de test HMAC-SHA1 sont disponibles
dans [RFC 2202](https://tools.ietf.org/html/rfc2202#section-3).

L'utilisation d'AES-GCM dans SRTP est définie dans [RFC 7714](https://tools.ietf.org/html/rfc7714).