[asterisk-users] is encrypted iax safe and secure?

[Tim Panton]

On 7 Feb 2008, at 00:36, Tilghman Lesher wrote:

> On Tuesday 05 February 2008 09:22:29 Cavalera Claudio Luigi wrote:
>> Hello,
>> I'm doing some research concerning iax encryption, I haven't find any
>> clients (softphones or hardphones) which implement so I have not  
>> tested
>> it yet.
>>
>> There was also this message on asterisk-security mailing list
>> http://archives.free.net.ph/message/20070507.101933.222987b2.en.html
>> which got no answers and this makes me think that this iax  
>> encryption is
>> not much interesting for the community.
>>
>> Anyway, in iax specification there is this statement:
>> "Only the data portion of the messages are encoded."
>>
>> Which are the consequences of this, is it true as stated on
>> http://www.voip-info.org/wiki/view/IAX+encryption
>> that
>> "The calling/called numbers are still passed in the clear over  
>> encrypted
>> IAX, so you are still vulnerable to traffic analysis."
>> ?
>>
>> If it's true how to deal with this?
>> Would you consider media payload encryption enough?
>> Maybe it's better to just forget about iax encryption and consider  
>> some
>> more general approach like using openvpn
>> http://www.voip-info.org/wiki/view/IAX_OpenVPN ?
>>
>> This half-encrypted iax encryption doesn't make much sense to me,
>> therefore I think there's probably something I'm
>> missing/misunderstanding.
>
> Is it important for you to conceal that a call was made from abc to  
> xyz on
> thus-and-such a date?  Or do you merely need to conceal the content  
> of a
> call?  You can already do traffic analysis and figure out that a call
> occurred, just not what the endpoints are (even if you encrypted the  
> entire
> link).  The only way to get around that is to continuously send  
> random garbage
> through the pipe at the same rate and consistency as would occur  
> with a real
> IAX2 call.  And the endpoints are only as specific as the systems on  
> either
> end choose to make them.  If you used some system of src/dst  
> obfuscation, you
> could conceal even that information, though repeated calls to various
> destinations could still be paired and correlated.
>
> IAX2 encryption is designed to obscure the same information as is  
> obscured
> when you encrypt a call over the PSTN -- the content is protected,  
> but the
> existence of such a call is not.  Remember that a potential attacker  
> will
> always choose the weakest link, and will probably attack the audio  
> stream
> at a different location, if she cannot listen to the IP stream  
> directly (such
> as a true wiretap on an analog endpoint or breaking into one of the  
> two
> machines involved in the encryption).  The idea is to make the IAX2  
> link
> unattractive as a potential target of wiretapping (whereas before it  
> would
> have been the most obvious choice), thus forcing the attacker to  
> choose a
> different attack scenario.
>
> -- 
> Tilghman
>
> ________________________


Also if you _really_ care about concealing the dialed number
you can do it just fine.

The simplest way is to have a single exten that takes _all_ encrypted  
calls,
then once the call is up, dial 'onwards' with DTMF, the DTMF frames  
would
be encrypted.

In fact IAX kinda supports this at the protocol level (although I  
don't know of a working implementation
apart from the iAXy perhaps, but that doesn't do crypto...).

The NEW frame doesn't _have_ to contain a dialed number, the digits  
can be sent later
(I forget the frametype), but later means within the encrypted  
session :-)

Tim.