Mi Brain-Training Personal

Buenas, amigos del SIP y derivados. Hoy os voy a contar una pequeña batalla que he tenido con el soporte de SRTP en su forma opcional.

Primero unos breves antecedentes, para entrar en materia:

¿Qué es SRTP?

SRTP (RFC 3711) define un perfil de RTP mediante el cual dota de encriptación a este protocolo. Como sabéis, se suele utilizar RTCP junto al RTP, por lo que también existe SRTCP, que se encarga de cifrar el tráfico RTCP. Básicamente lo que haremos será cifrar el audio utilizando AES, de manera que aunque alguien pudiera capturar nuestros paquetes no podrá escuchar nuestra conversación.

Lo más habitual es utilizar SIP sobre UDP, así que la señalización irá sin encriptar, por lo que es posible que las claves de cifrado que se usarán para cifrar el audio sean capturadas y por lo tanto el cifrado pueda romperse. Para solucionar esto podemos cifrar también la señalización, utilizando TLS, o podemos utilizar ZRTP, que permite el intercambio de claves a nivel de RTP, a través de un medio no fiable (Internet es muy hostil). ZRTP utiliza el mecanismo Diffie-Hellman para intercambiar las claves a través de RTP y poder empezar a utilizar así SRTP.

¿Cómo se usa?

Este post no pretende dar una explicación detallada sobre SRTP, básicamente nos bastará con saber que con SRTP ciframos el audio y al menos se lo ponemos más difícil a los malos 😉

Cuando utilizamos SRTP lo podemos hacer de 3 maneras:

• Deshabilitado: no utilizaremos SRTP.
• Opcional: se ofrecerá soporte de SRTP en el SDP, y el terminal remoto elegirá si desea utilizarlo o no.
• Obligatorio: únicamente se aceptarán streams que indiquen que SRTP está siendo utilizado.

Veamos como luce el SDP en los distintos casos:

SRTP desactivado:
v=0
o=- 3482506669 3482506669 IN IP4 192.168.99.53
s=sipsimple 0.14.2
c=IN IP4 192.168.99.53
t=0 0
m=audio 63697 RTP/AVP 103 102 9 0 8 101
a=rtcp:63698 IN IP4 62.131.6.55
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

Como se puede ver en la línea m del SDP, el perfil de RTP que estamos utilizando no es cifrado, ya que es RTP/AVP. (en caso de ser cifrado sería RTP/SAVP)

SRTP obligatorio:
v=0
o=- 3482507190 3482507190 IN IP4 192.168.99.53
s=sipsimple 0.14.2
c=IN IP4 192.168.99.53
t=0 0
m=audio 51474 RTP/SAVP 103 102 9 0 8 101
a=rtcp:51475 IN IP4 62.131.6.55
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:rbU4YeWyt+bRJPY2FZjIDfkPt659Az0lG05yVdQ9
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:/ebgRzBfmUVuD2aaqeZmVfFahAX3hakyi+k8oMn2
a=sendrecv

En este caso se trata de un SDP con SRTP habilitado, ya que el perfil es seguro (RTP/SAVP) y se indican las claves a utilizar mediante los atributos a=crypto.

SRTP opcional:
v=0
o=- 3482507190 3482507190 IN IP4 192.168.99.53
s=sipsimple 0.14.2
c=IN IP4 192.168.99.53
t=0 0
m=audio 51474 RTP/AVP 103 102 9 0 8 101
a=rtcp:51475 IN IP4 62.131.6.55
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=audio 51474 RTP/SAVP 103 102 9 0 8 101
a=rtcp:51475 IN IP4 62.131.6.55
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:rbU4YeWyt+bRJPY2FZjIDfkPt659Az0lG05yVdQ9
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:/ebgRzBfmUVuD2aaqeZmVfFahAX3hakyi+k8oMn2
a=sendrecv

Aquí vienen los problemas. Lo que se puede ver arriba es un SDP correcto indicar el soporte opcional de SRTP, pero ahora nos surgen problemas:

Tenemos 2 streams de audio: uno con SRTP y otro sin SRTP, pero no existe relación aparente. ¿Cómo se supone que ha de actuar una aplicación al recibir esto? Podríamos asumir que solo se permite un único stream de audio, ¡pero eso sería limitar las capacidades de SIP y SDP! ¡¿Qué hacemos?!

La solución más ampliamente utilizada (aunque incorrecta) es la siguiente:

v=0
o=- 3482507626 3482507626 IN IP4 192.168.99.53
s=sipsimple 0.14.2
c=IN IP4 192.168.99.53
t=0 0
m=audio 53519 RTP/AVP 103 102 9 0 8 101
a=rtcp:53520 IN IP4 62.131.6.55
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:Fx7O4v/cWkY0cdwn/X3G/RE5ei2hXWt9l4zuoDwo
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:2rhPrkeZ++0i0aSkrGuPP2c1DM/kq/RUKQsR9BH2
a=sendrecv

Como se puede ver estamos indicando un perfil de transporte inseguro (RTP/AVP) pero indicando las claves SRTP (atributos a=crypto).

La solución estándar

Como he comentado, la forma correcta de expresar el soporte opcional de SRTP es incluyendo 2 streams distintos de audio, pero no hay forma de correlacionarlos. Imaginemos el siguiente caso: estamos viendo una peli por SIP. El vídeo nos viene en un stream (m=video) y el audio en otro (m=audio). Además, tenemos un segundo stream de audio con los comentarios del director. Por tanto tendremos 1 stream de vídeo y 2 de audio, pero no hay relación entre ellos, así que ¿cómo sabemos si en realidad no hay comentarios del director o si se trata de soporte opcional de SRTP? ¿y si aceptamos los 2 streams que hacemos? Un jaleo.

Para solucionar esto tenemos el draft SDP Capability Negotiation (http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-13) gracias al cual sí que existe una relación entre los streams de audio y el soporte opcional de SRTP tiene sentido:

v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 53456 RTP/AVP 0 18
a=tcap:1 RTP/SAVP
a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
a=pcfg:1 t=1 a=1

Y ahora a esperar a que los fabricantes lo implementen. 🙁