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 )