Activity Log : GSoC Week #04-#05 (12.V - 25.V)

Unfortunately I didn't have more than a weekend free these weeks so this entry will be quite short:

• Regarding the problem I was talking about in my last post about how JMF (or FMJ) will handle the ZRTP packets, I think I've reached a conclusion, after I read the JMF samples here: http://java.sun.com/javase/technologies/desktop/media/jmf/2.1.1/solutions/ (the RTP streaming section) and took another quick look into the JMF API Guide (which wasn't of very much help though because it doesn't contain the RTP Manager/Connector additions). As a reminder: the RTPConnector "acts" on the packets passed by the RTPManager before these are sent into network and on the receiver side, before these are passed to the receiver's RTPManager. So, I believe there shouldn't be a problem with the different ZRTP header (as I thought it might be) as long as all ZRTP traffic is being held in the boundary of a ZRTP RTPConnector dedicated implementation, in a similar way like SRTP is. Otherwise, if the packets would "reach" the RTPManager, there will be a problem probably with the unknown Format, resulting in the need of registering a new one, and things might get a bit to complicated. In conclusion, I think the idea of using a ZRTP dedicated Connector and consequently keeping most of the ZRTP management related to it remains the best option.
• I also managed to make another comparison between the FMJ API and JMF one, on a few RTP related classes (did it once more at the start of GSoC), and as discussed on the dev list I can't find any differences (RTPConnector, RTPManager and few other classes included here). This, anyway, is only in rough API terms = looked at the function signatures provided by one and compared to the other. I decided to do this once more, after the problems Werner reported on the dev list with FMJ. I didn't manage to get deeper (I wanted actually to investigate a bit further about what are the differences related to the way ReceiveStreamEvent is handled - Werner's reported problem - between JMF and FMJ, but it seems that the JMF sources aren't available any longer on the Sun site: http://www.sun.com/software/communitysource/jmf/download.xml - eventually I'll look for them in other place). Anyway, as I said also on the mailing list, if the ZRTP solution will be based on the common API parts used by JMF and FMJ (which will be almost certain according to the comparison made above), it shouldn't be a problem on which of them is run and tested. Just as a fact, I personally did read a bit more about JMF in this first GSoC phase, so many assumptions are based on this knowledge - hope it applies on both of them (I tried to find some FMJ tutorials but there seems there aren't any - or I didn't look for them enough) .
• The next steps: fortunately this week I'll be over with my exams (one more research project next Tuesday but that won't be a problem), and I'll finally be able to use most of my time for GSoC beginning with the next week, so probably this weekend (or next Monday latest) I'll try writing the starting code for the RTPConnector based ideas mentioned above. I still must talk to Werner about what exactly his library ZRTP4J provides and any integration issues related to this (probably also Monday) and must see how I'll use the UIService to connect the GUI to the Connector part. All these probably in my next activity log entry :).

Activity Log : GSoC Week #03 (5.V - 11.V)

A bit late with the entry for this week, but better late than never :)

The activity for the third GSoC week was centered, as said in a previous post on reading the ZRTP standard and getting a bit deeper into the SC SRTP implementation.

I'll try in this entry to summarize the most important notes I took while reading the ZRTP standard.

First of all, I'm reproducing the typical establishment of SRTP using ZRTP diagram from the standard, for better understanding of the next comments, in case someone not very familiar with ZRTP will ever take a look on this blog:





There are many points in the standard where the operation of ZRTP is related to the signaling level. Most of them are concentrated in chapter 9 - Signaling Interactions, but are reminded also during the other chapters. Before reading the standard I was pro keeping the ZRTP integration as much as possible at the media level, in order for a possible support by various signaling protocols in the future, not only SIP. Anyway according to section 9 there are some advantages in interacting with the signaling protocol. Some examples are:

- advertising the ZRTP support through SDP (a=zrtp-hash attribute in the SDP offers and answers) which according to the standard permits an easily detection by other possible future implemented key management protocols and ease of implementing cooperation between these and ZRTP
- additional security support like preventing a third party to insert false media packets [section 9.1] but bringing also the drawback of possible DoS by an attacker who controls the signaling layer [also section 9.1]

However, regarding the fact that (quote from section 9): "ZRTP may be implemented without coupling with the SIP signaling", I still remain pro keeping the integration at the media level, at least for an early phase. Anyway, after all runs ok and it's stable, interacting with the signaling level probably should be considered.

Also related to the signaling level interaction is the discovery phase of ZRTP which is based on two options: including the a=zrtp-hash in SDP offers and answers or/and using an RTP extension field as a flag to indicate support. Regarding the above mentioned, I'll be in favor of the second option (for start at least).
About the actual integration in SC, I'm a bit unclear related to the discovery phase about how the ZRTP packets will be treated by JMF. In case of SRTP, the integration in SC, acts like a filter for the outgoing and incoming packets, but SRTP packets have a similar header with RTP, ZRTP ones don't. In conclusion, I don't know for the moment how the ZRTP packets, multiplexed on the same port through another RTPConnector derived class will be handled by JMF, and if a similar filtering like method will be enough (or additional operation like defining a specific format or other stuff related to the RTP/AVP profile is needed). Anyway, this week hopefully I'll have it made clear after I'l look one more time over the JMF API Guide and in the SC sources ( any possible helpful feedback is very much appreciated though :) )
Because I am at this point, regarding the filtering like approach through a Connector and TransformEngine (actually more like a CreateEngine in this case) classes as I was thinking from the GSoC eval phase, and also proposed by Werner Dittmann, in very very rough lines I think on this (from the sender point of view) like :

- the media stream in call starts
- if ZRTP is activated the Connector intercepts it and:

• in case ZRTP communication is needed, the neccessary packets are created and sent;
• this will be done through the usage of a Transform(Create)Engine and any additional classes as I thought initially, which after the recent news :) will be probably actually through a dedicated library (Werner's proposal), or through an Engine class which uses this library;
• the RTP stream that should be sent during this is dumped (the standard states that during Commit-Conf2Ack for the initiator, and during Commit-Confirm2 for the responder no media should be sent; in other cases of ZRTP communication besides SRTP activation this "no sending" rule also applies - should check again the standard anyway to see where doesn't);
• after the ZRTP communication ends, the media stream is again let to go through by the Communicator (of course if other rule like tearing down the session doesn't apply)

Like I said in my previous post, this is an opinion about integration pretty close to the one had during the GSoC eval phase, and also to the solution expressed by Werner, and I'm thinking to start a basic design for the classes based on it (e.g. the Connector, the Engine, etc) - (good to have some feedback here if possible too = would be a good approach or not).

Going forward with the standard related ideas, there is needed (like Werner said also) a way for the ZRTP implementation to communicate with the GUI. About how this should be done, my first idea relates to a GUI plugin as described in the dev page tutorial on the SC site, but I need to think more about how this should connect with the ZRTP implementation. For now, some parts that should need GUI support are:

• not related with the standard effectively, (but I'm thinking it would be necessary) an interface element, which should announce the user that some stream securing (ZRTP) activity is in progress, in order to make him aware about the reason for eventual silence periods (like said previously, the standard states that during some points of protocol transmission, no media stream should be sent; in addition to this, there are specified some retransmission timers for the protocol messages, so I think that possible long no-sound breakes might appear ... anyway, I'm far from being experienced with ZRTP exchange, so someone should correct me if I'm wrong)

• the SAS verification can be done according to the standard through verbal communication (actually reading the rendered string by the user), through exchanging and comparing over the signaling channel using the a=zrtp-sas attribute or validating a digital signature exchanged in the Confirm1 or Confirm2 messages; I'll personally be in favor of the last solution in order to have an automatic way of verification which won't rely on the user who might skip the SAS check, and without using the signaling channel; however, the digital signature exchange through the Confirm messages is supposed to be contained in a Signature Type Block which according to section 6.1.7. is subject of future standardization; anyway a signature algorithm could be selected for use, but due to the fact described above (and not only that) the SAS should be presented through GUI to the user allowing the posibility of verbal verification

• also related to the SAS and the GUI support, are the features described in section 5.3.3. of the standard -Handling a Secret Cache Mismatch; the user should be alerted in this case and also the standard implies that the possibility for the call to continue is available even in the case of a supposed MitM attack - so probably the user should be asked through a message box if he wants to go on or not (something similar "yes" or "no" option would also be needed through a GUI element triggered by the PBX enrollment procedure - section 8.3.1. which asks the user if he trusts a certain PBX for SAS relaying)

• the standard states that starting the actual encryption could be done later after sending the Hello messages, when the Commit is sent, and this action might be triggered by the user through a GO SECURE button; also the user could trigger the GoClear message through another GUI button/action in order to switch back to unencrypted media communication; there is a small issue to be taken into consideration here I think, this being related to how the GUI part of this feature is implemented and communicates with the ZRTP part, in order to permit other future key management protocols; these might permit crypted/unencrypted switch also and the user shouldn't be put in front of two or more buttons to choose from; in conclusion, the only one button used to GO SECURE should have the functionality implemented in such a way that it could be extended in the future when it should probably also initiate an automatic choice process from the supported key management protocols

Other ideas/issues/questions related to the standard:

• the first ZRTP message initiating the key exchange is the Hello (followed by HelloACK) message which will carry the SRTP configuration options and the ZID; the ZID, according to the standard is generated at ZRTP installation time, being unique and used to look up for retained shared secrets from previous ZRTP sessions with the endpoint; if I understand correctly the ZID may be generated once per application (SIP Communicator) run, before any ZRTP communication is done, in order to save time (need someone to correct me if I'm wrong)

• the standard describes along with the normal and multistream, the preshared mode as a posibility of keying; this does rely on the already shared secret in order to skip the DH exchange; the standard doen't recommend this due to the lack of PFS (Perfect Forward Secrecy), unless the call participant is very limited in resources; I'll personally leave it away for the early phase of ZRTP integration (or more exactly I'll leave it for later; it should be done however in order to keep the full support of the standard)

• I'm a bit uncertain about how the PBX SAS relaying should be implemented/supported; I'm reffering mostly on the actual mode of development, not on standard defined characteristics; more exactly the PBX should supply an enrollment extension; I'm not experienced at all with Asterisk (as a PBX example) so I really don't know if it (or other PBX) does supply this extension in order to test the implementation; I'll personally let this for a later phase of development because I should find out what PBX to use and how is this feature implemented (possible could use some feedback on this too, still I'd like to focus on some other issues first); anyway, the SAS PBX relay support could be implemented "blindly" according to the standard description, after all being intended to be supported by any PBX, and tested afterwards

In the end, other stuff done last week: checked (not very deep allthough - should go further when I got the time) to see if the SRTP implementation works with the standard BouncyCastle crypto library; for now it doesn't.

Related to BouncyCastle, I should check if all cryptographic related features mentioned by the ZRTP standard are supported through it (part of them are sure because there are also used in the SRTP implementation, but I don't know if all of them are there).

There are other minor notes I took on the ZRTP standard, but I think this is long enough already for a single post :). Anyway, I've read both standards and things are pretty much clear related to them exclusively. I'll start from now on to focus on the actual basic integration design in SC until the end of this month. (Hope I'll have the time... My final semester exam period starts next week )

Integration ideas discussion - from GSoC evaluation phase

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

Activity Log : GSoC Week #02 (28.IV - 4.V)

Going on with the analysis phase :

- done reading SRTP RFC 3711 to get a deeper view into the standard aspects that are related to the key mangement issue

- decided to take a more detailed look, in addition to the quick overview I had in the evaluation phase, on the current SRTP implementation, before reading the ZRTP draft (due to the fact I have the RFC still fresh in my mind at this moment)

- tried to identify the main connection points with any key management solution in the standard and also to "map" them with the current implementation (still in progress for the 2nd part) - in rough lines essentially the main issue of the key management in relation with SRTP would be translated for the current implementation in providing the cryptographic context info contained in the CryptoContext class in a secure way; anyway there are still other problems to be considered according to the standard in relation with any key management solution, one of the most important being the moments when re-keying is triggered which is taken into consideration in various sections of the standard (8.1, 9.2, 11.3)

- got a bit deeper into the JMF API to see how the RTP flow is managed and actually intercepted in the SRTP implemention (in progress - still have to look a bit more to clear some issues) - need this especially in case of a ZRTP implementation which acts at RTP level too

Sorry for the quite quick description above, I'm writing in a hurry 'cause I need to get done some labs homework - have more notes on specific points in the RFC which might be of some interest. I'll be back with these or with other any important encountered issues the next week (when I'll be finished with the in progress sections above), in addition to the hopefully "ZRTP done reading" status.

PS: I noticed since the overview I took on the sources the lack for SRTCP support in the current implementation. It came back now, when I've looked again more in depth. For now, it should be more simple in the key management to support only the SRTP part existent at the moment, and I'm thinking to focus on that (for start at least), but there are some issues (like re-keying, which according to the RFC depend more or less on the SRTCP part) and I wonder if this would be a good approach for now (at least for the start as I said)...

Later edit (answering to me): Probably it will be more clear a bit later in the analysis phase (after I'll read the ZRTP draft) .