[sip-comm-dev] ZRTP and conference calls


#1

Hi Werner,

recently we noticed a problem with conference calls and securing them.
The simple scenario in which the problems is reproduced is the
following:
A calls B and talk in one2one secure call, then A adds C to the call
and it becomes a conference call. As B was in a secure call and
because of the reinvites for the new participant the media streams are
reinitialized on the A side. And so the stream which was to B was with
for example sequence number 11625 is now with the same ssrc and with
new sequence number 31870(there is a change in the starting seq
number). And so the packets seem invalid for srtp and are discarded
and so B hears nothing.
I tried resetting the SRTPCryptoContext (recreate it on reinvites,
both for outgoing and for incoming), but without any permanent
success. Sometimes its ok, sometimes the srtp check for checkReplay
fails, sometimes these checks fail, which are after the checkReplay :
for (int i = 0; i < tagLength; i++) {
                if ((tempStore[i]&0xff) == (tagStore[i]&0xff))

I was wondering what is the proper way to handle this situation? Is it
recreating the SRTPCryptoContext or restarting the whole zrtp process
?

Thanks
damencho

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Damian,

several comments and questions:

- SRTP does not allow to modifiy the sequence numbers of the packets
  for the same SSRC within one RTP session, the packet sequence number
  goes into the material to encrypt/decrypt SRTP (actually in the
  Initialization Vector, IV)

- the replay mechanism checks for a replay of the last 64 packets,
  thus if the packet sequence number is out of order then the replay
  check rejects the packet

- then authentication mechanism (this is the loop you mention in your
  post) checks the whole packet with a HMAC, they key for the HMAC is
  the 48 bit sequence number (SRTP keeps track of the upper 32 bits
  of the sequence number, ROC -> Roll-Over-Counter)

-> to me this indicates that something with the packet sequence numbers
   is not ok.

Some notes: SRTPContext can handle one SRTP / RTP packet at a time. This
is usually no problem because each outgoing and incoming RTP session has
its own SRTPContext. SRTPContext is also not mult-thread aware, also
usually no problem -> a one-to-one relation to the RTP session is required.
SRTP context keeps states of the session (ROC for example, and the replay
window stuff).

If you have several sessions to different parties each session requires
its own SRTPContext -> otherwise SRTP cannot work. Thus for a normal
Audio session each party has 2 SRTP contexts (one for receiving data,
one for sending data).

If you reset the SRTP context (BTW, how do you do that? Do you store
the keys somewhere to do that?) then both parties must do that.

Looks like the whole packet synchronization is gone somehow. Make sure
that all SRTP sessions are really independent. Lets discuss the tech details
offline if necessary - and don't store key material.

If required just close the old SRTP sessions, stop and cleanup the ZRTP
classes and rebuild the whole stuff. Usually it just takes a short time
anyway.

Regards,
Werner

···

Am 27.04.2010 15:30, schrieb Damian Minkov:

Hi Werner,

recently we noticed a problem with conference calls and securing them.
The simple scenario in which the problems is reproduced is the
following:
A calls B and talk in one2one secure call, then A adds C to the call
and it becomes a conference call. As B was in a secure call and
because of the reinvites for the new participant the media streams are
reinitialized on the A side. And so the stream which was to B was with
for example sequence number 11625 is now with the same ssrc and with
new sequence number 31870(there is a change in the starting seq
number). And so the packets seem invalid for srtp and are discarded
and so B hears nothing.
I tried resetting the SRTPCryptoContext (recreate it on reinvites,
both for outgoing and for incoming), but without any permanent
success. Sometimes its ok, sometimes the srtp check for checkReplay
fails, sometimes these checks fail, which are after the checkReplay :
for (int i = 0; i < tagLength; i++) {
                if ((tempStore[i]&0xff) == (tagStore[i]&0xff))

I was wondering what is the proper way to handle this situation? Is it
recreating the SRTPCryptoContext or restarting the whole zrtp process
?

Thanks
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi,

Thanks for the quick answer.
(see inline)

Damian,

several comments and questions:

- SRTP does not allow to modifiy the sequence numbers of the packets
for the same SSRC within one RTP session, the packet sequence number
goes into the material to encrypt/decrypt SRTP (actually in the
Initialization Vector, IV)

- the replay mechanism checks for a replay of the last 64 packets,
thus if the packet sequence number is out of order then the replay
check rejects the packet

- then authentication mechanism (this is the loop you mention in your
post) checks the whole packet with a HMAC, they key for the HMAC is
the 48 bit sequence number (SRTP keeps track of the upper 32 bits
of the sequence number, ROC -> Roll-Over-Counter)

-> to me this indicates that something with the packet sequence numbers
is not ok.

Some notes: SRTPContext can handle one SRTP / RTP packet at a time. This
is usually no problem because each outgoing and incoming RTP session has
its own SRTPContext. SRTPContext is also not mult-thread aware, also
usually no problem -> a one-to-one relation to the RTP session is required.
SRTP context keeps states of the session (ROC for example, and the replay
window stuff).

If you have several sessions to different parties each session requires
its own SRTPContext -> otherwise SRTP cannot work. Thus for a normal
Audio session each party has 2 SRTP contexts (one for receiving data,
one for sending data).

If you reset the SRTP context (BTW, how do you do that? Do you store
the keys somewhere to do that?) then both parties must do that.

SRTPTransformer have mapping: ssrc - SRTPCryptoContext, and when I
need it I delete on both sides of the call this mappings and so new
SRTPCryptoContext object are created and mapped to the same ssrc.

Looks like the whole packet synchronization is gone somehow. Make sure
that all SRTP sessions are really independent. Lets discuss the tech details
offline if necessary - and don't store key material.

If required just close the old SRTP sessions, stop and cleanup the ZRTP
classes and rebuild the whole stuff. Usually it just takes a short time
anyway.

I'm testing this now, when needed I just recreate ZrtpControl and
initialise it as in the beginning of the session.

Thanks
damencho

···

On Tue, Apr 27, 2010 at 8:17 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Regards,
Werner

Am 27.04.2010 15:30, schrieb Damian Minkov:

Hi Werner,

recently we noticed a problem with conference calls and securing them.
The simple scenario in which the problems is reproduced is the
following:
A calls B and talk in one2one secure call, then A adds C to the call
and it becomes a conference call. As B was in a secure call and
because of the reinvites for the new participant the media streams are
reinitialized on the A side. And so the stream which was to B was with
for example sequence number 11625 is now with the same ssrc and with
new sequence number 31870(there is a change in the starting seq
number). And so the packets seem invalid for srtp and are discarded
and so B hears nothing.
I tried resetting the SRTPCryptoContext (recreate it on reinvites,
both for outgoing and for incoming), but without any permanent
success. Sometimes its ok, sometimes the srtp check for checkReplay
fails, sometimes these checks fail, which are after the checkReplay :
for (int i = 0; i < tagLength; i++) {
if ((tempStore[i]&0xff) == (tagStore[i]&0xff))

I was wondering what is the proper way to handle this situation? Is it
recreating the SRTPCryptoContext or restarting the whole zrtp process
?

Thanks
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi again,

I think I finally did it :slight_smile: All the time it was my mistake wrong
managing the transformer chain and the old zrtp engine stays on the
way and never get replaced with the new one.

Cheers
damencho

···

On Wed, Apr 28, 2010 at 10:54 AM, Damian Minkov <damencho@sip-communicator.org> wrote:

Hi,

Thanks for the quick answer.
(see inline)

On Tue, Apr 27, 2010 at 8:17 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Damian,

several comments and questions:

- SRTP does not allow to modifiy the sequence numbers of the packets
for the same SSRC within one RTP session, the packet sequence number
goes into the material to encrypt/decrypt SRTP (actually in the
Initialization Vector, IV)

- the replay mechanism checks for a replay of the last 64 packets,
thus if the packet sequence number is out of order then the replay
check rejects the packet

- then authentication mechanism (this is the loop you mention in your
post) checks the whole packet with a HMAC, they key for the HMAC is
the 48 bit sequence number (SRTP keeps track of the upper 32 bits
of the sequence number, ROC -> Roll-Over-Counter)

-> to me this indicates that something with the packet sequence numbers
is not ok.

Some notes: SRTPContext can handle one SRTP / RTP packet at a time. This
is usually no problem because each outgoing and incoming RTP session has
its own SRTPContext. SRTPContext is also not mult-thread aware, also
usually no problem -> a one-to-one relation to the RTP session is required.
SRTP context keeps states of the session (ROC for example, and the replay
window stuff).

If you have several sessions to different parties each session requires
its own SRTPContext -> otherwise SRTP cannot work. Thus for a normal
Audio session each party has 2 SRTP contexts (one for receiving data,
one for sending data).

If you reset the SRTP context (BTW, how do you do that? Do you store
the keys somewhere to do that?) then both parties must do that.

SRTPTransformer have mapping: ssrc - SRTPCryptoContext, and when I
need it I delete on both sides of the call this mappings and so new
SRTPCryptoContext object are created and mapped to the same ssrc.

Looks like the whole packet synchronization is gone somehow. Make sure
that all SRTP sessions are really independent. Lets discuss the tech details
offline if necessary - and don't store key material.

If required just close the old SRTP sessions, stop and cleanup the ZRTP
classes and rebuild the whole stuff. Usually it just takes a short time
anyway.

I'm testing this now, when needed I just recreate ZrtpControl and
initialise it as in the beginning of the session.

Thanks
damencho

Regards,
Werner

Am 27.04.2010 15:30, schrieb Damian Minkov:

Hi Werner,

recently we noticed a problem with conference calls and securing them.
The simple scenario in which the problems is reproduced is the
following:
A calls B and talk in one2one secure call, then A adds C to the call
and it becomes a conference call. As B was in a secure call and
because of the reinvites for the new participant the media streams are
reinitialized on the A side. And so the stream which was to B was with
for example sequence number 11625 is now with the same ssrc and with
new sequence number 31870(there is a change in the starting seq
number). And so the packets seem invalid for srtp and are discarded
and so B hears nothing.
I tried resetting the SRTPCryptoContext (recreate it on reinvites,
both for outgoing and for incoming), but without any permanent
success. Sometimes its ok, sometimes the srtp check for checkReplay
fails, sometimes these checks fail, which are after the checkReplay :
for (int i = 0; i < tagLength; i++) {
if ((tempStore[i]&0xff) == (tagStore[i]&0xff))

I was wondering what is the proper way to handle this situation? Is it
recreating the SRTPCryptoContext or restarting the whole zrtp process
?

Thanks
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net