[Asterisk-Security] Opportunistic encryption

[John Todd]

At 2:22 PM -0700 7/18/06, Bret McDanel wrote:
>On Tue, 2006-07-18 at 13:36 -0700, John Todd wrote:
>
>>  I also understand that there has at least been some discussion with
>>  Phil Zimmerman about ZRTP inclusion into Asterisk, though I don't
>>  know who (if anyone) at Digium has been talking with him about it
>>  (though I've brought it up enough with him to start looking like a
>>  pest.)
>
>As I understand the Zphone protocol, which may be wrong, its based off
>his speech at etel, so I really havent looked at tech docs, but ...  it
>seems that its end to end encryption which uses normal sip devices
>connected to a proxy running on a local system which then connects to
>another similar proxy (directly or indirectly).  This means that
>asterisk can only do pass through, as such it shouldnt be that difficult
>to implement it.
>
>I may be wrong about my interpretation of this, however the hash that is
>displayed would suggest that this is true (along with Phils comments
>about using a normal sip device). 
>
>He implied but didnt actually state that pretty much anything that
>bridges the two channels without transcoding will work - of course this
>means that whatever payload that is used has to be supported (ie not
>rejected, which may be listed as a totally different codec) and that its
>stanard RTP othwerise. 
>
>Of course this does nothing for the signalling layer, but its a good
>start.
>
>My interpretations may be wrong, and I would appreciate someone who
>knows correcting me if they are, as stated previously I really didnt
>read anything just let my imagination run away during his speech trying
>to visualize how it worked, and granted he only had 10 minutes or
>whatever to talk about it.


It is mostly as you describe it.  However, it fits the desire for an 
opportunistic encryption system - if it's there, it will make itself 
known.  If it's not, your client could possibly continue working 
without it in a less-secure fashion.

More notes on ZRTP:

ZRTP, like any encryption package, can be inserted into the middle of 
any media stream and used to a significant advantage even when the 
conversation is not "end-to-end" encrypted.  For instance, I would 
very much like to have my Asterisk server (with PRI cards) using ZRTP 
to my SIP or IAX softphones on my laptop.  I feel that the greatest 
risk from interception is on the IP portion of the call, and so I 
would be happy if Asterisk was a ZRTP speaker so that my calls to the 
PSTN were at least encrypted on the most insecure leg.

This encryption level can be automated if the appropriate hooks are 
installed into Asterisk.  I would see three types of ZRTP support:

   1) "Pass-through" mode where the media stream is not modified and 
routes through Asterisk's RTP stack.  The Asterisk server would of 
course not be able to do things like record the call, play MOH, or 
other media-specific tasks.  I am uncertain about RFC2833, but I 
suspect that too would be encrypted.  Asterisk needs(?) minor 
modifications to let the ZRTP encrypted packets go through when it 
sees certain packet signature types.  Of course, if for a particular 
call Asterisk isn't in the RTP path then it works like a charm 
already.

   2) "Termination" mode, where a call from a ZRTP client would be 
decrypted and the media relayed to a non-encrypted channel of choice 
- IAX, Zap, SCCP, etc.  This would involve giving the Asterisk server 
a ZRTP identity.  This, IMHO, would be the most common use of the 
ZRTP stack, since the bulk of calls are to the PSTN on most systems, 
and most PSTN providers don't have ZRTP (via Zap or normal RTP 
SIP/IAX2 connections.)  However, the server can typically be located 
on a much more secure network segment than the client, so there is a 
fairly good return on the encryption investment.

   3) "Man in the Middle" mode, where Asterisk creates two separate 
ZRTP legs to different ZRTP clients.  While this sounds like a 
security risk, it is actually a fairly desirable situation.  Many 
calls need to be recorded, or monitored for DTMF, or inserted into 
app_conference for group discussion.  Having each leg of the call 
encrypted to the Asterisk server but not encrypted in an "end-to-end" 
fashion would be frequent, I suspect.  The users could still verify 
that their calls were encrypted to the core, and interception would 
not be possible except on the Asterisk server itself.  This is just a 
modified version of "Termination" mode and would not require any 
additional programming I think, but is worth describing as it would 
mimic an unauthorized intercept but would not be unexpected by the 
end user.


I'm willing to put a few bucks towards ZRTP integration.  I don't 
know why Asterisk hasn't been the first platform tested - it really 
does seem like an ideal candidate for a variety of reasons.  Is there 
anyone else working on this?  I'm very sad that there is still only 
weak support for encryption on a single protocol in Asterisk.

JT