[Linphone-developers] Linphone Uses Wrong SRTP Crypto Suite

[Trevor Alpeter]

We have encountered a bug where Linphone uses the wrong SRTP crypto
suite. In our situation, Linphone was configured to offer
AES_CM_128_HMAC_SHA1_80 and AES_CM_128_HMAC_SHA1_32. Our server supports
those as well as AES_CM_256_HMAC_SHA1_80.

During SIP negotiation the server INVITEs using AES_CM_256_HMAC_SHA1_80
first, followed by the other two enabled suites. Since Linphone
internally supports AES_CM_256_HMAC_SHA1_80, it includes it in its
supported crypto suite list. Linphone then correctly negotiates
AES_CM_128_HMAC_SHA1_80 because of the client configuration.

However, after negotiating AES_CM_128_HMAC_SHA1_80 Linphone configures
itself to use AES 256. This results in both Linphone and the server
being unable to decrypt each other’s data.

The culprit appears to be linphone_call_start_audio_stream() in
linphone/coreapi/linphonecall.c. On lines 3444 and 3445 (in commit
776577c673edb18817c72a74952e62c7d9942134 on master), Linphone uses a
hardcoded index of 0 for the first supported crypto suite offered by the
remote party, which in this case is AES 256 rather than the negotiated
AES 128 suite.

We were able to work around this issue by changing our configurations
(to disable AES_256 on the server or enable it on the client). But this
behavior is incorrect — Linphone should ignore any crypto suite that it
is not configured to support.

I'm not sure of the best way to correct this behavior, but I wanted to
let you know what we found since it could impact other users.


Best regards,

Trevor