Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crypto #170

Open
GoogleCodeExporter opened this issue Mar 17, 2015 · 1 comment
Open

Crypto #170

GoogleCodeExporter opened this issue Mar 17, 2015 · 1 comment

Comments

@GoogleCodeExporter
Copy link

Hi Arsen,

are there any plans to design features involving encryption (essential for 
deploying UniMRCP as software-as-a-service) and implement them in medium-term 
future? I do not suppose so, but tried to create a ticket at least. :-)

- Vali

Original issue reported on code.google.com by [email protected] on 12 May 2014 at 2:43

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 27 May 2014 at 6:30

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant