[asterisk-bugs] [JIRA] (ASTERISK-26190) [patch] SRTP: Enable AES-256 and AES-GCM.

Thu Aug 11 02:05:56 CDT 2016

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-26190:
---------------------------------------

    Description: 
Encrypted media data (SRTP) uses so called ‘crypto suites’ similar to the ‘cipher suites’ in HTTPS:
- SIP over TLS: Those suites are negotiated via SDES ([RFC 4568|https://tools.ietf.org/html/rfc4568#section-6.2]). In 2006, Cisco finished their corresponding library libSRTP. SDES was added with Asterisk 1.8 in the year 2010.
- SIP over WebSockets: Those suites are negotiated via DTLS-SRTP ([RFC 5764|https://tools.ietf.org/html/rfc5764#section-4.1.2]). This was [added|https://reviewboard.asterisk.org/r/2113] with Asterisk 11 in the year 2012.

These specifications mandate a crypto suite which is based on AES-128/HMAC-SHA and is offered by Asterisk: {{AES_CM_128_HMAC_SHA1_80}}. Today, ten years later, this default crypto suite is still deemed secure. Therefore, attacks concentrate on other parts of the security architecture, like (D)TLS, the implementation itself or the storage of the private key.

Nevertheless, additional crypto suites were added to [SDES|https://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xhtml] and [DTLS|https://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml]. Since May 2010, libSRTP offers AES-256 ([RFC 6188|https://tools.ietf.org/html/rfc6188]). Since May 2015, libSRTP [offers|https://github.com/cisco/libsrtp/commit/d63d4f03c69dfd339834a1ff1511b53a23902b05] AES-GCM ([RFC 7714|https://tools.ietf.org/html/rfc7714]).

AES-256 was added in
- (02/2015) Media5-fone 4.1.3,
- (03/2015) Linphone 3.8,
- (03/2016) Acrobits Groundwire 3.3,
- (05/2016) PJSIP 2.5.

Because those VoIP/SIP clients still offer the mandatory AES-128 based crypto suite, no new interoperability issues arise. Except for Acrobits Groundwire → Settings → Preferences → Security → (SRTP) SDES, which allows the user to disable this crypto suite.

Long story short, the attached patch revolves this interoperability issue by adding support for all crypto suites offered by the underlying libSRTP. The current patch is just about SDES and not DTLS-SRTP. This is because there is no known WebRTC browser to test AES-GCM with. The solution would be to [patch OpenSSL|https://github.com/openssl/openssl/pull/521], patch an existing WebRTC browser and do the similar with {{res/res_rtp_asterisk.c}}.

The patch auto-detects the capabilities of your libSRTP. In many distributions, the pre-build libSRTP package does not come with AES-256 or AES-GCM. Therefore please, build libSRTP yourself, for example in Ubuntu 16.04 LTS
{noformat}sudo apt install libssl-dev
wget github.com/cisco/libsrtp/archive/1_5_x_throttle.tar.gz
tar zxf 1_5_*.tar.gz
./configure --disable-debug --disable-stdout --enable-openssl
make shared_library
sudo make install{noformat}

To enable this patch in Asterisk 13:{noformat}patch -p0 <./srtp_aead_and_big_aes.patch
CFLAGS='-DENABLE_SRTP_AES_256 -DENABLE_SRTP_AES_GCM' ./configure
make
sudo make install{noformat}

Words of caution:
- Some clients have spelling mistakes in the crypto-suite names and therefore the connection falls back to AES-128/HMAC-SHA.
- Nokia Belle (Symbian/S60) based mobile phones reject the whole SIP-INVITE with status 500 because the shorter crypto-suite name of AES-GCM. Therefore, no call is established when Asterisk starts the call (egress).
- AES-192 [created|https://github.com/cisco/libsrtp/pull/170] no-audio calls with all tested implementations. If you still want to offer AES-192 on egress calls, you have to add -DENABLE_SRTP_AES_192 to CFLAGS as well.
- AES-256 requires more processing power but might not add any additional security in your scenario. Please, see [this|https://security.stackexchange.com/q/61361] and [that|https://security.stackexchange.com/q/14068] for up to date information.
- AES-GCM started in October 2008 but is still rather new because its [RFC 7714|https://tools.ietf.org/html/rfc7714] was finalized in December 2015. Because there were [long|http://fm4.orf.at/stories/1737330/] [discussions|https://www.ietf.org/mail-archive/web/cfrg/current/msg07099.html] about the AEAD-Tag-Size suitable for VoIP application, libSRTP from May 2015 or newer is required. Even then, some implementations are [incompatible|https://github.com/cisco/libsrtp/pull/184]. I did not do any performance tests with AES-GCM because my server architecture is designed not to create much load and therefore this is of no matter to me. Please, have a tests, whether AES-GCM without its HMAC-SHA [helps|https://www.ietf.org/mail-archive/web/cfrg/current/msg02980.html] in your server load.

Long story short, you might be better off sticking to just {{AES_CM_128_HMAC_SHA1_80}} which Asterisk offers already. Therefore on default, all crypto suites offered by the underlying libSRTP are enabled only for ingress. When you have to go for additional suites on egress, please, enable those via CFLAGS as shown above.

  was:
Encrypted media data (SRTP) uses so called 'crypto suites' similar to the 'cipher suites' in HTTPS:
- SIP over TLS: Those suites are negotiated via SDES ([RFC 4568|https://tools.ietf.org/html/rfc4568#section-6.2]). In 2006, Cisco finished their corresponding library libSRTP. SDES was added with Asterisk 1.8 in the year 2010.
- SIP over WebSockets: Those suites are negotiated via DTLS-SRTP ([RFC 5764|https://tools.ietf.org/html/rfc5764#section-4.1.2]). This was [added|https://reviewboard.asterisk.org/r/2113] with Asterisk 11 in the year 2012.

These specifications mandate a crypto suite which is based on AES-128/HMAC-SHA and is offered by Asterisk: {{SRTP_AES128_CM_HMAC_SHA1_80}}. Today, ten years later, this default crypto suite is still deemed secure. Therefore, attacks concentrate on other parts of the security architecture, like (D)TLS, the implementation itself or the storage of the private key.

Nevertheless, additional crypto suites were added to [SDES|https://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xhtml] and [DTLS-SRTP|https://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml]. Since May 2010, libSRTP offers AES-256 ([RFC 6188|https://tools.ietf.org/html/rfc6188]). Since May 2015, libSRTP [offers|https://github.com/cisco/libsrtp/commit/d63d4f03c69dfd339834a1ff1511b53a23902b05] AES-GCM ([RFC 7714|https://tools.ietf.org/html/rfc7714]).

AES-256 was added in
- (02/2015) Media5-fone 4.1.3,
- (03/2015) Linphone 3.8,
- (03/2016) Acrobits Groundwire 3.3,
- (05/2016) PJSIP 2.5.

Because those VoIP/SIP clients still offer the mandatory AES-128 based crypto suite, no new interoperability issues arise. Except for Acrobits Groundwire → Settings → Preferences → Security → (SRTP) SDES, which allows the user to disable this crypto suite.

Long story short, the attached patch revolves this interoperability issue by adding support for all crypto suites offered by the underlying libSRTP. The current patch is just about SDES and not DTLS-SRTP. This is because there is no known WebRTC browser to test AES-GCM with. The solution would be to [patch OpenSSL|https://github.com/openssl/openssl/pull/521], patch an existing WebRTC browser and do the similar with {{res/res_rtp_asterisk.c}}.

The patch auto-detects the capabilities of your libSRTP. In many distributions, the pre-build libSRTP package does not come with AES-256 or AES-GCM. Therefore please, build libSRTP yourself, for example in Ubuntu 16.04 LTS
{noformat}sudo apt install libssl-dev
wget github.com/cisco/libsrtp/archive/1_5_x_throttle.tar.gz
tar zxf 1_5_*.tar.gz
./configure --disable-debug --disable-stdout --enable-openssl
make shared_library
sudo make install{noformat}

To enable this patch in Asterisk 13:{noformat}patch -p0 <./srtp_aead_and_big_aes.patch
CFLAGS='-DENABLE_SRTP_AES_256 -DENABLE_SRTP_AES_GCM' ./configure
make
sudo make install{noformat}

Words of caution:
- Some clients have spelling mistakes in the crypto-suite names and therefore the connection fails back to AES-128/HMAC-SHA.
- Nokia Belle (Symbian/S60) based mobile phones reject the whole SIP-INVITE with status 500 because the shorter crypto-suite name of AES-GCM. Therefore, no call is established when Asterisk starts the call (egress).
- AES-192 [created|https://github.com/cisco/libsrtp/pull/170] no-audio calls with all tested implementations. If you still want to offer AES-192 on egress calls, you have to add -DENABLE_SRTP_AES_192 to CFLAGS as well.
- AES-256 requires more processing power but might not add any additional security in your scenario. Please, see [this|https://security.stackexchange.com/q/61361] and [that|https://security.stackexchange.com/q/14068] for up to date information.
- AES-GCM started in October 2008 but is still rather new because its [RFC 7714|https://tools.ietf.org/html/rfc7714] was finalized in December 2015. Because there were [long|http://fm4.orf.at/stories/1737330/] [discussions|https://www.ietf.org/mail-archive/web/cfrg/current/msg07099.html] about the AEAD-Tag-Size suitable for VoIP application, libSRTP from May 2015 or newer is required. I did not do any performance tests with AES-GCM because my server architecture is designed not to create much load and therefore this is of no matter to me. Please, have a tests, whether AES-GCM without its HMAC-SHA [helps|https://www.ietf.org/mail-archive/web/cfrg/current/msg02980.html] in your server load.

Long story short, you might be better off sticking to just {{SRTP_AES128_CM_HMAC_SHA1_80}} which Asterisk offers already. Therefore on default, all crypto suites offered by the underlying libSRTP are enabled only for ingress. When you have to go for additional suites on egress, please, enable those via CFLAGS as shown above.

> [patch] SRTP: Enable AES-256 and AES-GCM.
> -----------------------------------------
>
>                 Key: ASTERISK-26190
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26190
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Resources/res_srtp
>            Reporter: Alexander Traud
>            Assignee: Alexander Traud
>            Severity: Minor
>      Target Release: 14.0.0
>
>         Attachments: srtp_aead_and_big_aes.patch
>
>
> Encrypted media data (SRTP) uses so called ‘crypto suites’ similar to the ‘cipher suites’ in HTTPS:
> - SIP over TLS: Those suites are negotiated via SDES ([RFC 4568|https://tools.ietf.org/html/rfc4568#section-6.2]). In 2006, Cisco finished their corresponding library libSRTP. SDES was added with Asterisk 1.8 in the year 2010.
> - SIP over WebSockets: Those suites are negotiated via DTLS-SRTP ([RFC 5764|https://tools.ietf.org/html/rfc5764#section-4.1.2]). This was [added|https://reviewboard.asterisk.org/r/2113] with Asterisk 11 in the year 2012.
> These specifications mandate a crypto suite which is based on AES-128/HMAC-SHA and is offered by Asterisk: {{AES_CM_128_HMAC_SHA1_80}}. Today, ten years later, this default crypto suite is still deemed secure. Therefore, attacks concentrate on other parts of the security architecture, like (D)TLS, the implementation itself or the storage of the private key.
> Nevertheless, additional crypto suites were added to [SDES|https://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xhtml] and [DTLS|https://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml]. Since May 2010, libSRTP offers AES-256 ([RFC 6188|https://tools.ietf.org/html/rfc6188]). Since May 2015, libSRTP [offers|https://github.com/cisco/libsrtp/commit/d63d4f03c69dfd339834a1ff1511b53a23902b05] AES-GCM ([RFC 7714|https://tools.ietf.org/html/rfc7714]).
> AES-256 was added in
> - (02/2015) Media5-fone 4.1.3,
> - (03/2015) Linphone 3.8,
> - (03/2016) Acrobits Groundwire 3.3,
> - (05/2016) PJSIP 2.5.
> Because those VoIP/SIP clients still offer the mandatory AES-128 based crypto suite, no new interoperability issues arise. Except for Acrobits Groundwire → Settings → Preferences → Security → (SRTP) SDES, which allows the user to disable this crypto suite.
> Long story short, the attached patch revolves this interoperability issue by adding support for all crypto suites offered by the underlying libSRTP. The current patch is just about SDES and not DTLS-SRTP. This is because there is no known WebRTC browser to test AES-GCM with. The solution would be to [patch OpenSSL|https://github.com/openssl/openssl/pull/521], patch an existing WebRTC browser and do the similar with {{res/res_rtp_asterisk.c}}.
> The patch auto-detects the capabilities of your libSRTP. In many distributions, the pre-build libSRTP package does not come with AES-256 or AES-GCM. Therefore please, build libSRTP yourself, for example in Ubuntu 16.04 LTS
> {noformat}sudo apt install libssl-dev
> wget github.com/cisco/libsrtp/archive/1_5_x_throttle.tar.gz
> tar zxf 1_5_*.tar.gz
> ./configure --disable-debug --disable-stdout --enable-openssl
> make shared_library
> sudo make install{noformat}
> To enable this patch in Asterisk 13:{noformat}patch -p0 <./srtp_aead_and_big_aes.patch
> CFLAGS='-DENABLE_SRTP_AES_256 -DENABLE_SRTP_AES_GCM' ./configure
> make
> sudo make install{noformat}
> Words of caution:
> - Some clients have spelling mistakes in the crypto-suite names and therefore the connection falls back to AES-128/HMAC-SHA.
> - Nokia Belle (Symbian/S60) based mobile phones reject the whole SIP-INVITE with status 500 because the shorter crypto-suite name of AES-GCM. Therefore, no call is established when Asterisk starts the call (egress).
> - AES-192 [created|https://github.com/cisco/libsrtp/pull/170] no-audio calls with all tested implementations. If you still want to offer AES-192 on egress calls, you have to add -DENABLE_SRTP_AES_192 to CFLAGS as well.
> - AES-256 requires more processing power but might not add any additional security in your scenario. Please, see [this|https://security.stackexchange.com/q/61361] and [that|https://security.stackexchange.com/q/14068] for up to date information.
> - AES-GCM started in October 2008 but is still rather new because its [RFC 7714|https://tools.ietf.org/html/rfc7714] was finalized in December 2015. Because there were [long|http://fm4.orf.at/stories/1737330/] [discussions|https://www.ietf.org/mail-archive/web/cfrg/current/msg07099.html] about the AEAD-Tag-Size suitable for VoIP application, libSRTP from May 2015 or newer is required. Even then, some implementations are [incompatible|https://github.com/cisco/libsrtp/pull/184]. I did not do any performance tests with AES-GCM because my server architecture is designed not to create much load and therefore this is of no matter to me. Please, have a tests, whether AES-GCM without its HMAC-SHA [helps|https://www.ietf.org/mail-archive/web/cfrg/current/msg02980.html] in your server load.
> Long story short, you might be better off sticking to just {{AES_CM_128_HMAC_SHA1_80}} which Asterisk offers already. Therefore on default, all crypto suites offered by the underlying libSRTP are enabled only for ingress. When you have to go for additional suites on egress, please, enable those via CFLAGS as shown above.

--
This message was sent by Atlassian JIRA
(v6.2#6252)