Crypto - Githubissues

Hi Arsen,

I can try, with your guidance, implement the crypto myself. A brief analysis 
follows.

All the features should be optional from both client-side and server-side, on 
compile-time and run-time. On the other hand, they should be enforcable by 
configuration. I would focus on MRCPv2, when finished, securing MRCPv1 (if 
needed) should be straightforward.

I see three stages of the issue: SIP, TCP/MRCPv2 and RT(C)P; from easiest to 
hardest.

1. Sofia-SIPS (transport=tls)

Certificate file names and other things hardcoded in Sofia-SIP, location 
specified just by directory. I would stick to this and design the features 
accordingly.

Default certificates/keys location:
conf/agent.pem, conf/cafile.pem (optionally conf/tls_seed.dat).

Common crypto params:
<properties>
  <!-- Security level -->
  <security>0..off 1..tolerated 2..preferred 3..required</security>
  <!-- Certificate and key directory -->
  <cert-dir>conf/</cert-dir>
  <!-- Private key passphrase -->
  <pk-passphrase>XXXX</pk-passphrase>
  <!-- SSL or TLS -- according to Sofia -->
  <tls-version>0..SSL 1..TLS</tls-version>
  <!-- Require valid client certificate or check server cert -->
  <tls-verify-peer>0..off 1..on</tls-verify-peer>
  <!-- List of allowed peers -->
  <x509-subjects>
    <subj>CN=nnn/O=mmm/...</subj>
  </x509-subjects>
</properties>

GNU build of Sofia detects OpenSSL automatically, on Windows, some files must 
be added to its VS project and OpenSSL must be enabled in config.h. Of course, 
OpenSSL must be availabe. I suggest let users install it and set up default 
include and library paths of Visual C++. Then I suggest to patch the affected 
Sofia sources so that only editing config.h would be necessary, i.e. enclose 
entire content of the added files in an #ifdef.

New attributes (inheritable from <properties>) of <sip-uac> and <sip-uas>:
<security>
<cert-dir>
<pk-passphrase>
<tls-version>
<tls-verify-peer>
<x509-subjects>

<sip-port> and <sip-transport> may be omitted -- equivalent to security=3.

New attributes for UAS and UAC:
<sips-port>8061</sips-port>
<sips-transport>tls</sips-transport>

New attributes for UAC settings:
<server-sips-port>8061</server-sips-port>

2. TCP/MRCPv2

Detect OpenSSL in GNU build and in Windows build (props and vsprops?).

New attributes (inheritable from <properties>) of <mrcpv2-uac> and <mrcpv2-uas>:
<security>
<cert-dir>
<pk-passphrase>
<tls-version>
<tls-verify-peer>
<x509-subjects>

<mrcp-port> may be omitted -- equivalent to security=3.

New attributes for UAS:
<mrcp-tls-port>1545</mrcp-tls-port>

SDP offer for security=0 (unchanged):
  m=application 9 TCP/MRCPv2 1
SDP offer for security=1 [rfc5939]:
  m=application 9 TCP/TLS/MRCPv2 1
  a=tcap:1 TCP/MRCPv2
  a=pcfg:1 t=1
SDP offer for security=2 [rfc5939]:
  m=application 9 TCP/MRCPv2 1
  a=tcap:1 TCP/TLS/MRCPv2
  a=pcfg:1 t=1
SDP offer for security=3:
  m=application 9 TCP/TLS/MRCPv2 1

Implement apt_tls_(accept,connect,send,recv) to be used transparently with TLS 
socket and incorporate to mrcp_connection.

3. SRTP

Add libsrtp to dependencies.

New attributes (inheritable from <properties>) of <rtp-factory>:
<security>

SDP offer for security=0 (unchanged):
  m=audio 4000 RTP/AVP 0 8 96 101
SDP offer for security=1:
  rfc5939:
    m=audio 4000 RTP/SAVP 0 8 96 101
    a=tcap:1 RTP/AVP
    a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj
    a=pcfg:1 t=1
SDP offer for security=2:
  rfc5939:
    m=audio 4000 RTP/AVP 0 8 96 101
    a=tcap:1 RTP/SAVP
    a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj
    a=pcfg:1 t=1 a=1
  unofficial, but sometimes used, will also be accepted:
    m=audio 4000 RTP/AVP 0 8 96 101
    a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj
SDP offer for security=3:
  m=audio 4000 RTP/SAVP 0 8 96 101
  a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj

Implement crypto requirement and keying fields to rtp_descriptor and apply SRTP.

Request for SRTP should be rejected if signaling (RTSP or SIP) is not secure, 
or at least logged with high severity and accepted for debugging purposes.

Alternatively (later), DTLS/SRTP may be implemented and it should be the 
preferred option.

When the time comes, I will create a new branch and start committing to it. Or 
would you prefer to do it in my repo and when usable results appear, commit it 
as a whole?

- Vali
Original comment by tomas.valenta@speechtech.cz on 27 May 2014 at 6:30
MattRiddell / unimrcp

Crypto #170
