- 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 :).
Tuesday, May 27, 2008
Thursday, May 15, 2008
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 )
Friday, May 9, 2008
Monday, May 5, 2008
- 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) .