I'm reproducing some parts of the discussion had in the evaluation phase of my GSoC application related to the ZRTP integration, in response to Werner Dittmann's integration proposal (made on SC dev list) - may still be useful for common knowledge.
Note: These comments are a month old now, before GSoC started (later edit: so they may have some faults, I've just selected & copy paste what seemed to be relevant to the integration matter, without any recheck). I'll be back during next week (as said in my previous post) with more actual and close related to the subject info after I finish reading also the ZRTP draft. Anyway, I was also and I'll probably remain quite close to Werner's ideas expressed on the dev list regarding the integration, he seeming to have a far better knowledge of ZRTP than I do at the moment. As discussed in the evaluation phase I was actually planning to use his implementation of libzrtpcpp as reference code for integrating ZRTP.
04/04/08 09:04
Romain Kuntz
Hi Emanuel,
Thank you for your detailed answers! Though it would deserve more discussion in the first part of the project, I'm actually also quite in favor of using ZRTP. For that purpose, libzrtpcpp is a good reference code, as you also guessed! On the library side, actually bouncycastle will be of a great help to implement ZRTP with Java, you may have a look at its features.
Did you have a little look at the SRTP implementation we have? Do you have some rough idea on how to integrate a key sharing protocol in SIP Communicator?
Again, thank you for your answers!
Cheers,
romain
04/04/08 23:04
Emanuel Onica
Hello,
Yes, I did have a very very quick look on the SRTP implementation. As far as I am able to tell at this point (without analyzing it more in depth, which I intend to do) it seems to work in the next way:
The base classes and interfaces are included in the impl.media.transform package, which seem to be a pretty good RTP packet transform base for any protocols that will "flow" through the same channel as RTP does (and for this reason I think on the ZRTP option).
The TransformManager class has the role to create a TransformConnector type class specific to the used transformation protocol. This is done based on the SessionAddress object and a protocol specific TransformEngine, passed as arguments in the constructor.
The TransformConnector obtains the RTP/RTCP input/output streams from the sockets got from the SessionAdress.
These streams are actually TransformInput/OutputStream type and their creation implies also the PacketTransformer, passed as argument in the constructor, which is obtained from the specific protocol Engine. The transformation of the packet seems to be called in the streams read, respectively write methods and imply the call of the method provided by the stream's associated implementation of the PacketTransformer.
The specific PacketTransformer for a certain protocol is provided by a specific TransformEngine (and provides specific transformation routines).
In case of SRTP these and the other SRTP specific classes are included in the impl.media.transform.srtp package.
Among these there is the SRTPCryptoContext created in the SRTP engine which holds the SRTP specific data. The context is accessible from the specific PacketTransformer. This calls in its transform and reverseTransform functions other implementations of transformation routines provided in the associated context class. Here, in the associated context, the RTP/RTCP packet is passed through the actual transformations i think.
Regarding the integration of the key sharing protocol I'll refer for the moment at ZRTP, because like we discussed it seems the appropriate solution.
I only have a basic view (described at the initial application beginning) at this moment over how SRTP works, and about ZRTP I know mainly also only the facts already described ( that's why one of the first tasks I planned is reading the RFC's :) ), so I'm not very sure at this point how exactly should look a possible integration of ZRTP near the already done SRTP implementation. The main issue here finally is to provide the resulting ZRTP shared secret to the SRTP implementation. The point where this could be done I think it could be the instantiation of the SRTPTransformEngine in the createSRTPConnector function from the TransformManager. For the actual implementation of the ZRTP at this moment I have two very basic ideas (from which I don't know if any of them is appropriate for the matter):
- one would be to integrate the ZRTP implementation based on the current media.transform package through the same steps the SRTP is done (writing a specific ZRTP TransformEngine, PacketTransformer, CryptoContext, etc), and the result should interconnect somehow with the SRTP one
- one would be to actually modify the current SRTP implementation and add ZRTP support somehow directly in it based on the fact that ZRTP key exchange occurs only at specific points in the SRTP flow;
My view on the subject is like I said based on a very quick look on the sources and on the limited overview I had on SRTP and ZRTP. Most probably I'm wrong on some aspects, for this being necessary like I said to read the RFC's and to see exactly how ZRTP works and how it relates to SRTP, and also to take a more in-depth look at the sources.
[...]
In the end I mustn't forget to thank you for the information on bouncycastle. I took a (also very quick) look on the API and I think it would prove useful. It seems that it has support among others for Diffie-Hellman key exchange primitives, and as far as I know ZRTP is based on DH exchange.
Thank you also very much for the feedback on my opinions!
Regards,
E. Onica
04/07/08 08:04
Romain Kuntz
Hi Emanuel,
[...]
About the integration of ZRTP (or any other key sharing protocol), I was thinking about having something separated from SRTP as long as possible. That would allow in the future to implement other key exchange protocols and would let the user choose the one he wants to use.
[...]
Cheers,
romain
04/13/08 12:04
Emil Ivov
Hi Emanuel,
A quick question from me:
Do you already know which parts of SIP Communicator your would need to implement in order to implement support for ZRTP?
Thanks
Emil
04/14/08 13:04
Emanuel Onica
Hello,
Like I already stated in my previous comment, I personally would be in favor of integrating ZRTP (and only ZRTP, not other key exchange protocol) through an extension of the current media.transform package. This idea is based mainly on the specific level on which ZRTP operates, inside the media flow. In order not to "bind" the ZRTP very tight to the current SRTP implementation, I think the extension may consist in actually implementing a media.transform.ZRTP package in a similar way with the SRTP one, which should also intercept the RTP flow through a TransformConnector specific implementation, create the ZRTP key exchange packets and send them at the specific times it is needed, inside the normal SRTP traffic.
The other idea I had was to actually modify the SRTP implementation and integrate the ZRTP support directly in it but Romain said in a previous comment that it would be desired to have something separated from SRTP. In the idea described above some points or means of synchronization between SRTP and ZRTP should be defined anyway. But, as far as I know, from the short overviews of ZRTP I've read, its operation is "silent" to put it in one word (that's the "opportunistic encryption" I've mentioned in the application). So, if I got the idea right, if one point doesn't support ZRTP this mustn't disturb the normal media flow, which will continue unencrypted.
In conclusion, my opinion is that, particularly in case of ZRTP, both of my ideas would work eventually. Until other key exchange protocol, will be implemented, SIP Communicator will try to use ZRTP and "silently" switch to unencrypted media if ZRTP isn't supported on the other side. In the future when other key exchange solutions will be available, the same thing will happen, but if the other side doesn't support ZRTP, SIP Communicator would switch to trying other key exchange protocol at the signalling level (or viceversa, from the signaling level to ZRTP). Like I said, I believe this is an appropriate solution mainly because ZRTP is as far as I know the only key exchange solution which does work exclusively at the media flow level and not at the signaling one.
Anyway, like I said in my previous comments, I should read first the ZRTP draft (and SRTP RFC) to see exactly how it works (my statements at this moment are based on some short overviews I've read on ZRTP). After that I should check how libzrtpcpp integrates with ccRTP in the applications it is used, because like I said this would probably give me a good reference view about the integration of ZRTP in SIP Communicator (which might differ from the current ideas).
[...]
Regards,
E. Onica
No comments:
Post a Comment