[jitsi-dev] Question about encryption with SDES key exchange


#1

Hi all,

When testing SDES key exchange mechanism to add information to the CallInfoFrame, I have seen the following behavior (corresponding to Jisti svn revision #9424):

[Configuration with SIP protocol using SDES and with TCP for the control transport protocol (no TLS)].

[JITSI point of view]

The call info frame display that the SDES mechanism is successful (information based on the CallPeerMediaHandler.srtpControls), but the CallPanel shows an open padlock.

[WIRESHARK point of view]

Wireshark displays the following SDES key exchange (which seems to work correctly), but display media packets only as RTP one (no SRTP):
PCA -> PCB SIP/SDP INVITE with:
- Media Attribute (a): crypto: 1 AES_CM_128_HMAC_SHA1_80 inline: ABC...
- Media Attribute (a): crypto: 1 AES_CM_128_HMAC_SHA1_32 inline: 123...

PCB -> PCA SIP/SDP 200 OK with:
- Media Attribute (a): crypto: 1 AES_CM_128_HMAC_SHA1_80 inline: XYZ...

PCA -> PCB SIP ACK.

Does someone knows:

- Why for wireshark, the key exchange seems to work correctly and nevertheless it sees only RTP media packets? In contrary for ZRTP, wireshark displays correctly SRTP media packets once the key exchange is done).

- Why for Jitsi, the padlock on the CallPanel does not correspond to the information available in the CallPeerMediaHandler.srtpControls?

Cheers,
Chenzo

···

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org


#2

Hey Vincent

When testing SDES key exchange mechanism to add information to the
CallInfoFrame, I have seen the following behavior (corresponding to
Jisti svn revision #9424):

[Configuration with SIP protocol using SDES and with TCP for the control
transport protocol (no TLS)].

[JITSI point of view]

The call info frame display that the SDES mechanism is successful
(information based on the CallPeerMediaHandler.srtpControls), but the
CallPanel shows an open padlock.

The padlock is open because you used TCP, not TLS. SDES is completely insecure if TLS is not used.

[WIRESHARK point of view]

Wireshark displays the following SDES key exchange (which seems to work
correctly), but display media packets only as RTP one (no SRTP):
PCA -> PCB SIP/SDP INVITE with:
- Media Attribute (a): crypto: 1 AES_CM_128_HMAC_SHA1_80 inline: ABC...
- Media Attribute (a): crypto: 1 AES_CM_128_HMAC_SHA1_32 inline: 123...

PCB -> PCA SIP/SDP 200 OK with:
- Media Attribute (a): crypto: 1 AES_CM_128_HMAC_SHA1_80 inline: XYZ...

PCA -> PCB SIP ACK.

Does someone knows:

- Why for wireshark, the key exchange seems to work correctly and
nevertheless it sees only RTP media packets? In contrary for ZRTP,
wireshark displays correctly SRTP media packets once the key exchange is
done).

What was the RTP/SAVP setting when you did that test? I'm not sure, but I think Wireshark interprets the RTP packages according to the indication in the SDP (because RTP and SRTP differ only by the added checksum, which would require inspecting the end of each packet).

- Why for Jitsi, the padlock on the CallPanel does not correspond to the
information available in the CallPeerMediaHandler.srtpControls?

Just because an SrtpControl is present, doesn't mean that it's actually used. This is true for ZRTP as well as SDES. The security is truly enabled when the SrtpControl calls securityTurnedOn on the SrtpListener. The padlock is marked as secure once the (event is received AND the transport is TLS) OR (event received AND requireSecureTransport is false)

Cheers,
Chenzo

Regards,
Ingo


#3

Hey Vincent

When testing SDES key exchange mechanism to add information to the

- Why for wireshark, the key exchange seems to work correctly and
nevertheless it sees only RTP media packets? In contrary for ZRTP,
wireshark displays correctly SRTP media packets once the key exchange is
done).

What was the RTP/SAVP setting when you did that test? I'm not sure, but I think
Wireshark interprets the RTP packages according to the indication in the SDP (because
RTP and SRTP differ only by the added checksum, which would require inspecting the end of each packet).

Right - Wireshark is not able to distinguish between RTP and SRTP. One has to look
to the contents to check wether scrutity is enabled. For example I use a special
audio soure (Sine wave encoded as PCM) to compare the normal versus the encrypted
contents in RTP.

Regards,
Werner

···

Am 02.03.2012 18:07, schrieb Ingo Bauersachs:

- Why for Jitsi, the padlock on the CallPanel does not correspond to the
information available in the CallPeerMediaHandler.srtpControls?

Just because an SrtpControl is present, doesn't mean that it's actually used. This is true for ZRTP as well as SDES. The security is truly enabled when the SrtpControl calls securityTurnedOn on the SrtpListener. The padlock is marked as secure once the (event is received AND the transport is TLS) OR (event received AND requireSecureTransport is false)

Cheers,
Chenzo

Regards,
Ingo