[jitsi-users] audio/video encryption


#1

Hi all,

if I understood correctly, not always the video connection
is encrypted.

What's the reason?

I assume the audio is *always* encrypted, is this correct?

Thanks,

bye,

···

--

piergiorgio


#2

Hi again,

I just realize the question was a bit "quick".

The story is as following.

After the ZRTP key setup, the SRTP is activated and,
overing the mouse on the locksmith, it is shown the
encryption status.

Usually the audio channel results to be encrypted.

Now, after activating the video connection and
checking again the encryption status, it is shown
that the video is not encrypted.

I was reading, I guess in some old email, that the
video is not always encrytped.

I was wondering how is the decision taken, i.e. why
it is sometimes encrypted and sometimes not.

Furtheremore, I was also wondering if the same
"strategy" could apply to the audio, or id it is
always encrypted.

Thanks again,

bye,

···

On Sun, Jan 08, 2012 at 09:39:40PM +0100, Piergiorgio Sartor wrote:

Hi all,

if I understood correctly, not always the video connection
is encrypted.

What's the reason?

I assume the audio is *always* encrypted, is this correct?

Thanks,

bye,

--

piergiorgio

--

piergiorgio


#3

Hey there,

Video should always be encrypted just as audio. The fact that it isnt is a
bug and we'll be looking into it soon.

-- sent from my mobile

···

On Jan 14, 2012 10:59 PM, "Piergiorgio Sartor" <piergiorgio.sartor@arcor.de> wrote:

Hi again,

I just realize the question was a bit "quick".

The story is as following.

After the ZRTP key setup, the SRTP is activated and,
overing the mouse on the locksmith, it is shown the
encryption status.

Usually the audio channel results to be encrypted.

Now, after activating the video connection and
checking again the encryption status, it is shown
that the video is not encrypted.

I was reading, I guess in some old email, that the
video is not always encrytped.

I was wondering how is the decision taken, i.e. why
it is sometimes encrypted and sometimes not.

Furtheremore, I was also wondering if the same
"strategy" could apply to the audio, or id it is
always encrypted.

Thanks again,

bye,

On Sun, Jan 08, 2012 at 09:39:40PM +0100, Piergiorgio Sartor wrote:
> Hi all,
>
> if I understood correctly, not always the video connection
> is encrypted.
>
> What's the reason?
>
> I assume the audio is *always* encrypted, is this correct?
>
> Thanks,
>
> bye,
>
> --
>
> piergiorgio

--

piergiorgio


#4

Hey

I looked into this again and tried some patches, but the problem really is in ZRTP and I don't know enough about its internals to really fix it.
Werner: Apart from 3) this is really ZRTP-stuff. Could you please take a look?

There are three problems:
1) The ZRTP video encryption is supposed to start once the audio is successfully encrypted. This should happen in the securityTurnedOn-Event from the Audio-Session, which transfers the encryption-data to the video-stream. But securityTurnedOn is fired when video is not yet enabled, which results in the video encryption is never being started.

I attempted to patch that by calling startSrtpMultistream from within CallPeerMediaHandler.setVideoStream so it would be guaranteed to be called. This works fine for calls that start with audio and are then "upgraded" to video. But for video-calls it fails within ZRtp because the multistream data is not yet available.
This in turn could probably be handled if the video-ZRTPControl listens on secretsReady of the master-ZRTPControl instead of assuming that the data is ready when setMultistream is called.

2) Uni-Directional streams: As far as I can tell, ZRTP currently only works with bi-directional streams within Jitsi (or maybe even the whole protocol?).

3) The Jitsi Call-UI incorrectly shows the lock icon when only one of the streams of the call is encrypted. The Call-UI must somehow be informed about the number of (active) streams associated with the call to correctly calculate the lock-status. This must be reported independently of the encryption-events (otherwise we'd be back to the current situation).

Regards,
Ingo

···

-----Original Message-----
From: Emil Ivov [mailto:emcho@jitsi.org]
Sent: Sonntag, 15. Januar 2012 01:25
To: users@jitsi.java.net
Subject: [jitsi-users] Re: audio/video encryption
Hey there,

Video should always be encrypted just as audio. The fact that it isnt is a
bug and we'll be looking into it soon.

-- sent from my mobile

On Jan 14, 2012 10:59 PM, "Piergiorgio Sartor" > <piergiorgio.sartor@arcor.de> wrote:

  Hi again,

  I just realize the question was a bit "quick".

  The story is as following.

  After the ZRTP key setup, the SRTP is activated and,
  overing the mouse on the locksmith, it is shown the
  encryption status.

  Usually the audio channel results to be encrypted.

  Now, after activating the video connection and
  checking again the encryption status, it is shown
  that the video is not encrypted.

  I was reading, I guess in some old email, that the
  video is not always encrytped.

  I was wondering how is the decision taken, i.e. why
  it is sometimes encrypted and sometimes not.

  Furtheremore, I was also wondering if the same
  "strategy" could apply to the audio, or id it is
  always encrypted.

  Thanks again,

  bye,

  On Sun, Jan 08, 2012 at 09:39:40PM +0100, Piergiorgio Sartor wrote:
  > Hi all,
  >
  > if I understood correctly, not always the video connection
  > is encrypted.
  >
  > What's the reason?
  >
  > I assume the audio is *always* encrypted, is this correct?
  >
  > Thanks,
  >
  > bye,
  >
  > --
  >
  > piergiorgio

  --

  piergiorgio


#5

Hi Emil,

thanks for the answer.

Maybe the question could be, then, rephrased:

Is the video encryption really not active or the
indication (of being not active) is wrong?

Is there any way to verify, from outside, if
the video is not encypted?

How about "wireshark"?

Thanks,

bye,

pg

···

On Sun, Jan 15, 2012 at 01:25:26AM +0100, Emil Ivov wrote:

Hey there,

Video should always be encrypted just as audio. The fact that it isnt is a
bug and we'll be looking into it soon.

-- sent from my mobile
On Jan 14, 2012 10:59 PM, "Piergiorgio Sartor" <piergiorgio.sartor@arcor.de> > wrote:

> Hi again,
>
> I just realize the question was a bit "quick".
>
> The story is as following.
>
> After the ZRTP key setup, the SRTP is activated and,
> overing the mouse on the locksmith, it is shown the
> encryption status.
>
> Usually the audio channel results to be encrypted.
>
> Now, after activating the video connection and
> checking again the encryption status, it is shown
> that the video is not encrypted.
>
> I was reading, I guess in some old email, that the
> video is not always encrytped.
>
> I was wondering how is the decision taken, i.e. why
> it is sometimes encrypted and sometimes not.
>
> Furtheremore, I was also wondering if the same
> "strategy" could apply to the audio, or id it is
> always encrypted.
>
> Thanks again,
>
> bye,
>
> On Sun, Jan 08, 2012 at 09:39:40PM +0100, Piergiorgio Sartor wrote:
> > Hi all,
> >
> > if I understood correctly, not always the video connection
> > is encrypted.
> >
> > What's the reason?
> >
> > I assume the audio is *always* encrypted, is this correct?
> >
> > Thanks,
> >
> > bye,
> >
> > --
> >
> > piergiorgio
>
> --
>
> piergiorgio
>

--

piergiorgio


#6

Hey

The video is actually really not encrypted :frowning:
Depending on the protocol you use (SIP or XMPP), the encryption can be enabled when you and your peer use video:

XMPP:
Audio call, then upgrade to video: Not possible to enable it
Video call: initially no encryption, after video is enabled from peer, security is on

SIP:
Video security is only on when _both_ peers enable video (no matter whether it's an audio or video call at first).

Regards,
Ingo

···

-----Original Message-----
From: Piergiorgio Sartor [mailto:piergiorgio.sartor@arcor.de]
Sent: Sonntag, 15. Januar 2012 18:01
To: users@jitsi.java.net
Subject: [jitsi-users] Re: audio/video encryption
Hi Emil,

thanks for the answer.

Maybe the question could be, then, rephrased:

Is the video encryption really not active or the
indication (of being not active) is wrong?

Is there any way to verify, from outside, if
the video is not encypted?

How about "wireshark"?

Thanks,

bye,

pg

On Sun, Jan 15, 2012 at 01:25:26AM +0100, Emil Ivov wrote:

Hey there,

Video should always be encrypted just as audio. The fact that it isnt is a
bug and we'll be looking into it soon.

-- sent from my mobile On Jan 14, 2012 10:59 PM, "Piergiorgio Sartor"
<piergiorgio.sartor@arcor.de> wrote:

Hi again,

I just realize the question was a bit "quick".

The story is as following.

After the ZRTP key setup, the SRTP is activated and,
overing the mouse on the locksmith, it is shown the
encryption status.

Usually the audio channel results to be encrypted.

Now, after activating the video connection and
checking again the encryption status, it is shown
that the video is not encrypted.

I was reading, I guess in some old email, that the
video is not always encrytped.

I was wondering how is the decision taken, i.e. why
it is sometimes encrypted and sometimes not.

Furtheremore, I was also wondering if the same
"strategy" could apply to the audio, or id it is
always encrypted.

Thanks again,

bye,

On Sun, Jan 08, 2012 at 09:39:40PM +0100, Piergiorgio Sartor wrote:

Hi all,

if I understood correctly, not always the video connection
is encrypted.

What's the reason?

I assume the audio is *always* encrypted, is this correct?

Thanks,

bye,

--

piergiorgio

--

piergiorgio


#7

Hi all,

Hey

I looked into this again and tried some patches, but the problem really is in ZRTP and I don't know enough about its internals to really fix it.
Werner: Apart from 3) this is really ZRTP-stuff. Could you please take a look?

There are three problems:
1) The ZRTP video encryption is supposed to start once the audio is successfully encrypted. This should happen in the securityTurnedOn-Event from the Audio-Session, which transfers the encryption-data to the video-stream.

That's correct. The assumption when we build ZRTP and the master/slave streams
was that we _always_ will have an audio call first, then a viedo call is established
after the audio session. To overcome this limitation we would need a new
implementation of the way how Jitsi starts and enables streams. But this
would take some time and testing.

But securityTurnedOn is fired when video is not yet enabled, which results in the video encryption is never being started.

At least it stuff worked some time ago. I didn't follow all the changes that were made to
set-up audio/video calls. When I looked at this some longer time ago the video call
fetched the parameters from the active audio (master) stream. Maybe something changed
here.

I attempted to patch that by calling startSrtpMultistream from within CallPeerMediaHandler.setVideoStream so it would be guaranteed to be called. This works fine for calls that start with audio and are then "upgraded" to video. But for video-calls it fails within ZRtp because the multistream data is not yet available.
This in turn could probably be handled if the video-ZRTPControl listens on secretsReady of the master-ZRTPControl instead of assuming that the data is ready when setMultistream is called.

As said above: we asumed that we always have audio first. It could be changed to a
more flexible way of handling it, but this would take some work and testing.

2) Uni-Directional streams: As far as I can tell, ZRTP currently only works with bi-directional streams within Jitsi (or maybe even the whole protocol?).

True, only bi-directonal calls are supported. We had this discussion a long time ago
already. It is partly (mainly) based on the ZRTP protocol specification because ZRTP
requires as per RFC the bothe parties know thier repective SSRC. An this is only
possible in bi-directional streams. Also in unidirectional streams it would not
be possible to verify the SAS (read the string aloud and compare). BTW, this would
also render pure video calls, i.e. without an audio channel, insecure because there
is now way the check the SAS, except is was verified before

3) The Jitsi Call-UI incorrectly shows the lock icon when only one of the streams of the call is encrypted. The Call-UI must somehow be informed about the number of (active) streams associated with the call to correctly calculate the lock-status. This must be reported independently of the encryption-events (otherwise we'd be back to the current situation).

IIRC the lock icon pops up if the audio channel is encrypted (via ZRTP, I don't know
the handling for SDES though). If the video channel was added the icon didn't change
but the tooltip showed that both channels (audio and video) were secure and which
algorithms are in force.

As said, this stuff worked quite nicely some time ago.

Best regards,
Werner

PS: please use line-breaks when writing e-mails. Some e-mail clients don't
automatically wrap lines at window borders. It would make e-mails easier to
reads. Thanks.

Werner

···

Am 15.01.2012 17:59, schrieb Bauersachs Ingo:

Regards,
Ingo

-----Original Message-----
From: Emil Ivov [mailto:emcho@jitsi.org]
Sent: Sonntag, 15. Januar 2012 01:25
To: users@jitsi.java.net
Subject: [jitsi-users] Re: audio/video encryption
Hey there,

Video should always be encrypted just as audio. The fact that it isnt is a
bug and we'll be looking into it soon.

-- sent from my mobile

On Jan 14, 2012 10:59 PM, "Piergiorgio Sartor" >> <piergiorgio.sartor@arcor.de> wrote:

  Hi again,

  I just realize the question was a bit "quick".

  The story is as following.

  After the ZRTP key setup, the SRTP is activated and,
  overing the mouse on the locksmith, it is shown the
  encryption status.

  Usually the audio channel results to be encrypted.

  Now, after activating the video connection and
  checking again the encryption status, it is shown
  that the video is not encrypted.

  I was reading, I guess in some old email, that the
  video is not always encrytped.

  I was wondering how is the decision taken, i.e. why
  it is sometimes encrypted and sometimes not.

  Furtheremore, I was also wondering if the same
  "strategy" could apply to the audio, or id it is
  always encrypted.

  Thanks again,

  bye,

  On Sun, Jan 08, 2012 at 09:39:40PM +0100, Piergiorgio Sartor wrote:
  > Hi all,
  >
  > if I understood correctly, not always the video connection
  > is encrypted.
  >
  > What's the reason?
  >
  > I assume the audio is *always* encrypted, is this correct?
  >
  > Thanks,
  >
  > bye,
  >
  > --
  >
  > piergiorgio

  --

  piergiorgio


#8

Hey

I looked into this again and tried some patches, but the problem really
is in ZRTP and I don't know enough about its internals to really fix
it. Werner: Apart from 3) this is really ZRTP-stuff. Could you please
take a look?

There are three problems:
1) The ZRTP video encryption is supposed to start once the audio is
successfully encrypted. This should happen in the securityTurnedOn-Event

from

the Audio-Session, which transfers the encryption-data to the

video-stream.

That's correct. The assumption when we build ZRTP and the master/slave
streams was that we _always_ will have an audio call first, then a viedo
call is established after the audio session. To overcome this limitation
we would need a new implementation of the way how Jitsi starts and
enables streams. But this would take some time and testing.

It's still the case that there is an audio stream first. Kind of. If you
start a video call, then the audio stream is still created first, but the
video stream is started immediately after the audio stream.

But securityTurnedOn is fired when video is not yet enabled, which

results in

the video encryption is never being started.

At least it stuff worked some time ago. I didn't follow all the changes
that were made to set-up audio/video calls. When I looked at this some
longer time ago the video call fetched the parameters from the active
audio (master) stream. Maybe something changed here.

I discovered this issue the first time when I tested my SRTP implementation
and thought I caused it. I therefore checked in previous builds (without any
SRTP stuff in them) and they also didn't work. The only other modifications
to encryption I remember since watching the project were the modifications
of Seb related to switching between video and desktop (May 2011, you
intervened there).

I attempted to patch that by calling startSrtpMultistream from within
CallPeerMediaHandler.setVideoStream so it would be guaranteed to be

called.

This works fine for calls that start with audio and are then "upgraded"

to

video. But for video-calls it fails within ZRtp because the multistream

data

is not yet available.
This in turn could probably be handled if the video-ZRTPControl listens

on

secretsReady of the master-ZRTPControl instead of assuming that the data

is

ready when setMultistream is called.

As said above: we asumed that we always have audio first. It could be

changed

to a
more flexible way of handling it, but this would take some work and

testing.

See above.

2) Uni-Directional streams: As far as I can tell, ZRTP currently only
works with bi-directional streams within Jitsi (or maybe even the whole
protocol?).

True, only bi-directonal calls are supported. We had this discussion a
long time ago already. It is partly (mainly) based on the ZRTP protocol
specification because ZRTP requires as per RFC the bothe parties know
thier repective SSRC. An this is only possible in bi-directional
streams. Also in unidirectional streams it would not be possible to
verify the SAS (read the string aloud and compare). BTW, this would also
render pure video calls, i.e. without an audio channel, insecure because
there is now way the check the SAS, except is was verified before

If the audio stream is bi-directional and sets up a secured session. The
secrets for a uni-directional stream would have to be passed over the
audio-stream. And isn't that what the whole multistream stuff is for?

3) The Jitsi Call-UI incorrectly shows the lock icon when only one of the
streams of the call is encrypted. The Call-UI must somehow be informed

about

the number of (active) streams associated with the call to correctly
calculate the lock-status. This must be reported independently of the
encryption-events (otherwise we'd be back to the current situation).

IIRC the lock icon pops up if the audio channel is encrypted (via ZRTP,
I don't know the handling for SDES though). If the video channel was
added the icon didn't change but the tooltip showed that both channels
(audio and video) were secure and which algorithms are in force.

The lock-icon is shown when the audio-call is secured, yes. But if one peer
adds a video stream, the lock icon stays in place, even though the
uni-directional video stream is not encrypted. This is wrong.

As said, this stuff worked quite nicely some time ago.

If you say that uni-directional video-streams are not supported, then the
lock icon was probably never correct.

What matters now is that it doesn't work (anymore) and we need to fix it.
I'd (we'd) be thankful if you could work on that because you know ZRTP best.

Best regards,
Werner

Regards,
Ingo

PS: please use line-breaks when writing e-mails. Some e-mail clients don't
automatically wrap lines at window borders. It would make e-mails easier

to

reads. Thanks.

Say "thanks" to our Exchange server. I'll try to send over Jitsi.org from
now on, I hope it's better...


#9

Hey

...

There are three problems:
1) The ZRTP video encryption is supposed to start once the audio is
successfully encrypted. This should happen in the securityTurnedOn-Event

from

the Audio-Session, which transfers the encryption-data to the

video-stream.

That's correct. The assumption when we build ZRTP and the master/slave
streams was that we _always_ will have an audio call first, then a viedo
call is established after the audio session. To overcome this limitation
we would need a new implementation of the way how Jitsi starts and
enables streams. But this would take some time and testing.

It's still the case that there is an audio stream first. Kind of. If you
start a video call, then the audio stream is still created first, but the
video stream is started immediately after the audio stream.

Without having a deeper look (not on my dev system at the moment) the video
(slave) stream must be started after _or_ must be sychronized with the audio
(master) stream. That means: only after the audio stream signals "secureOn"
(call back function) the video stream shall proceed to setup it session and
start ZRTP. Starting ZRTP can be done after the video session is already
active. You need to switch off "auto start" of ZRTP when starting the
second session and once the master session reaches security then transfer
the keying data from master to slave and then enable auto start etc. Would
this be acceptable?

Im not sure, but I believe we once had such a check ond sync mechanism, but
I my err here. I can check the logs once I'm back on my dev system.

But securityTurnedOn is fired when video is not yet enabled, which

results in

the video encryption is never being started.

At least it stuff worked some time ago. I didn't follow all the changes
that were made to set-up audio/video calls. When I looked at this some
longer time ago the video call fetched the parameters from the active
audio (master) stream. Maybe something changed here.

I discovered this issue the first time when I tested my SRTP implementation
and thought I caused it. I therefore checked in previous builds (without any
SRTP stuff in them) and they also didn't work. The only other modifications
to encryption I remember since watching the project were the modifications
of Seb related to switching between video and desktop (May 2011, you
intervened there).

I attempted to patch that by calling startSrtpMultistream from within
CallPeerMediaHandler.setVideoStream so it would be guaranteed to be

called.

This works fine for calls that start with audio and are then "upgraded"

to

video. But for video-calls it fails within ZRtp because the multistream

data

is not yet available.
This in turn could probably be handled if the video-ZRTPControl listens

on

secretsReady of the master-ZRTPControl instead of assuming that the data

is

ready when setMultistream is called.

As said above: we asumed that we always have audio first. It could be

changed

to a
more flexible way of handling it, but this would take some work and

testing.

See above.

2) Uni-Directional streams: As far as I can tell, ZRTP currently only
works with bi-directional streams within Jitsi (or maybe even the whole
protocol?).

True, only bi-directonal calls are supported. We had this discussion a
long time ago already. It is partly (mainly) based on the ZRTP protocol
specification because ZRTP requires as per RFC the bothe parties know
thier repective SSRC. An this is only possible in bi-directional
streams. Also in unidirectional streams it would not be possible to
verify the SAS (read the string aloud and compare). BTW, this would also
render pure video calls, i.e. without an audio channel, insecure because
there is now way the check the SAS, except is was verified before

If the audio stream is bi-directional and sets up a secured session. The
secrets for a uni-directional stream would have to be passed over the
audio-stream. And isn't that what the whole multistream stuff is for?

The multistream is the same protocol as the "normal" flow with one exception:
the Diffie-Helman key-negotiation is skipped and some computed data from the master
session is used. The Hello phase, etc stays the same, also the handling
and exchange of SSRC stays the same. Multi-stream is just a way to reduce
the compute effort to set-up a second, third, ... related media stream. Important
for low CPU devices.

3) The Jitsi Call-UI incorrectly shows the lock icon when only one of the
streams of the call is encrypted. The Call-UI must somehow be informed

about

the number of (active) streams associated with the call to correctly
calculate the lock-status. This must be reported independently of the
encryption-events (otherwise we'd be back to the current situation).

IIRC the lock icon pops up if the audio channel is encrypted (via ZRTP,
I don't know the handling for SDES though). If the video channel was
added the icon didn't change but the tooltip showed that both channels
(audio and video) were secure and which algorithms are in force.

The lock-icon is shown when the audio-call is secured, yes. But if one peer
adds a video stream, the lock icon stays in place, even though the
uni-directional video stream is not encrypted. This is wrong.

But the audio stream is istill encrypted? If yes then the lock should stay
because the audio is still encrypted. Agreed, we may need to add some information
that the second stream is not encrypted, normally this is shown in the
tooltip if you hover with the mouse over the lock.

Best regards,
Werner

As said, this stuff worked quite nicely some time ago.

If you say that uni-directional video-streams are not supported, then the
lock icon was probably never correct.

What matters now is that it doesn't work (anymore) and we need to fix it.
I'd (we'd) be thankful if you could work on that because you know ZRTP best.

Best regards,
Werner

Regards,
Ingo

PS: please use line-breaks when writing e-mails. Some e-mail clients don't
automatically wrap lines at window borders. It would make e-mails easier

to

reads. Thanks.

Say "thanks" to our Exchange server. I'll try to send over Jitsi.org from
now on, I hope it's better...

Definitely better, thanks alot :slight_smile:

Werner

···

Am 16.01.2012 17:48, schrieb Ingo Bauersachs: