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

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246099#comment-246099 ] 

Asterisk Team commented on ASTERISK-26190:
------------------------------------------

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.

> [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
>              Labels: patch, pjsip, webrtc
>      Target Release: 14.0.0, 15.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
> - (11/2008) *innovaphone V7*,
> - (02/2015) Media5-fone 4.1.3,
> - (03/2015) Linphone 3.8,
> - (08/2015) Avaya 96x1 SIP, Avaya H1xx SIP, Avaya J100 SIP,
> - (03/2016) *Acrobits Groundwire 3.3*,
> - (05/2016) PJSIP 2.5,
> - (08/2018) LANCOM Systems LCOS 10.20.
> AES-GCM was added in
> - (07/2018) Cisco IP Phones with Multiplatform Firmware 11.2 (SKU must contain 3PCC)
> Because VoIP/SIP clients have to offer the mandatory AES-128 based crypto suite, no new interoperability issues arise. However, two clients allow to be configured for only AES-256 by the user:
> - innovaphone → Web interface → Phone (→ General) → SRTP Cipher
> - Acrobits Groundwire → Settings → Preferences → Security → (SRTP) SDES
> One client allows to be configured for only AES-GCM by the user:
> - Cisco → Web interface → Admin → VoIP → Ext
> Long story short, the attached patch revolves those interoperability issues by adding support for all crypto suites offered by the underlying libSRTP. The current patch is just about SDES-SRTP 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)