[sip-comm-dev] Secure (encrypt) several media streams using ZRTP


#1

All,

some first thoughts on this topic.

The latest version of ZRTP4J (1.3.1) implements the multi-stream mode
as specified in the ZRTP draft. This involved some changes and
enhancements in the ZRTP4J core functions.

*** How does it work ***

According to ZRTP specification:

1) only one media stream (usually the first one) MUST use a full
    fledged Diffie-Helman (DH) key negotiation,

2) All other media streams for the same call MUST use multi-stream
    mode. However, multi-stream mode exchange can start only after the
    fist DH mode exchange is completed.

These requirements imply some synchronization of ZRTP exchanges,
however it's not too difficult to do this. ZRTP4J already reports when
a client can start a multi-stream ZRTP exchange.

Despite the fact the multi-stream exchanges re-use some data from the
DH ZRTP exchange (beefed up with nonces) each multi-stream session has
it own, independent set of key, hash, and HMAC data.

*** Setting up of several media streams ***

If a client likes to set up several media streams for _the same call_
it should use the following call flow. This is already a bit aligned
with SC's working using JMF (or FMJ):

The application shall create the required RTPManagers for the media
streams. SC already creates RTPManagers for audio and video. If both
media streams shall be encrypted then create the required numbers of
ZRTPConnectors and set these in the RTPManagers.

Remember: A ZRTPConnector behaves like a standard JMF RTP connector
until it is initialized to use ZRTP.

Now the more tricky part:

The application has to decide which media stream is the first one - in
ZRTP terms this will be the ZRTP exchange that must use a DH mode
exchange. Usually this is the audio stream. Thus the client (SC) shall
initialize the according ZRTPTransformer and it's associated ZRTP
engine to use ZRTP. Without specific configuration this will be a
DH mode exchange.

All other ZRTPTransformers stay in "non-ZRTP" mode (not initialized)
and just send the media (RTP) data if their RTP session is up and
running

If the first media stream is up and running and both clients support
ZRTP the key negotiation starts. After a short time this is done and
the first media stream (lets call it the "master stream") switches to
secure mode. ZRTP4J reports this event using the showMessage(...)
callback method with appropriate information codes. This callback
method shall prepare to switch on security for all other streams.

This is done as follows:

The first ZRTP exchange, the "master stream", computed a set of data
that all multi-stream ZRTP exchanges must use.

- The showMessage(...) callback method calls the ZRTP engine's
   method "getMultiStrParams()" to read this data from the master stream
   and sends it to all other ZRTPTransformers and their associated ZRTP
   engines using their "setMultiStrParams(...) method. This enables
   multi-stream processing for these streams.

- After this was done the client (SC) can initialize the remaining
   ZRTP engines as usual. The multi-stream negotiations may run in
   parallel.

Examples how this works in reality refer to the examples in ZRTP4J
demo directory :slight_smile: .

*** Notes on the current implementation of SC CallSessionImpl ***

The current implementation in SC's CallSessionImpl was done before the
multi-stream mode was ready in ZRTP4J, thus we probably need to revise
some code and mechanisms in SC's CallSessionImpl as well as in the SC
specific ZRTPTransformer classes. The latter ones need a small update
only as far as I can see. The mechanisms in CallSessionImpl are nearly
available, however because I don't know all the callback and event
handling mechanisms in SC during call setup I cannot propose a way to
do it but are ready to start discussions.

Regards,
Werner

···

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


#2

Hey Werner,

The latest version of ZRTP4J (1.3.1) implements the multi-stream mode
as specified in the ZRTP draft.

Hey this is very nice! Thanks for the notification!

Werner Dittmann написа:

only as far as I can see. The mechanisms in CallSessionImpl are nearly
available, however because I don't know all the callback and event
handling mechanisms in SC during call setup I cannot propose a way to
do it but are ready to start discussions.

Changing the callback mechanisms has been on my todo list for the past
few days. The point is to replace them with interfaces and events
defined exclusively in the media package. This is supposed to make them
easier to understand, modify, and work with. This way they would also
better fit the rest of our architecture.

As soon as I am done with this (hopefully before Friday this week), we
can chat on the multi streaming implementation. (And I'd greatly
appreciate your help on this).

Cheers
Emil

···

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