[Asterisk-Dev] AES voice encryption for IAX2

Derek Smithies derek at indranet.co.nz
Sun Apr 18 18:06:01 MST 2004


Adam,

> I shutter at the thought but either way, it's a decision not to be made 
> quite yet. Let's discuss other issues
I hate to think about it also, but, let us get used to it, and move on.

=============
Replay attacks are a real problem.
See, you listen in to one conversation.
Then, you use their initial packet to "connect with" and you are making 
some progress toward either a)DOS attack or b)making a call.

Adam suggested:
> NEW (with username :|) ->
> AUTHREQ <-  (with MD5 challenge and cipher challenge)
> AUTHREP -> (cipher challenge encrypted by AES using the result of the 
> MD5 sum as the key)


I see no reason for transmitting the username in the clear.
If we are going to be secure, we are going to be secure. Consequently, we 
cannot transmit username in the clear.
Further,
 Sending New first, and then sending voice (before the authrep/authreq 
 exchange completes)  is nonsensical, as the remote party cannot decode 
 our voice packets.

We could do it as::
 AUTHREQ <-  (with MD5 challenge and cipher challenge)
 AUTHREP -> (cipher challenge encrypted by AES using the result of the 
               MD5 sum as the key)
 NEW (with username, and other setup parameters) ->

yes, a change in protocol. Well, we better get used to it, cause a change 
will be required to be secure.

The other change will be that it will take something less than a second
(guess) to setup a secure relationship, before voice is sent.
This is quite different to current, where voice starts immediately.



Derek.
  
=======================================================================
 
On Mon, 19 Apr 2004, Adam Hart wrote:

> Derek Smithies wrote:
> 
> >HI,
> > I agree.
> > As explained in my previous emails, there are numerous attacks one can do 
> >if the signalling information is not encrypted.
> >  I have explained a denial of service attack, where a third party can 
> >   disconnect an active call.
> >  A third party has other DOS attacks, interjecting dtmf digits in the 
> >    stream.
> >  The attacks as listed below, where the bank account details are 
> >   readable.
> >
> >Let us move this conversation to:::
> >
> >encrypting the entire contents of all iax2 packets.
> >
> >  
> >
> Indeed :)
> 
> >There seems to be  opposition to some sort of vpn. The preference is that 
> >encryption goes in at the application layer. Although, I do remember a 
> >post arguing that the IETF are moving towards encryption at the OS level.
> >   (apologies  if I misquoted that)
> >
> >Does that mean::
> >If we insist on do encryption at the application layer, and we decide
> >to encrypt the entire contents of all iax packets
> >    ===> we require iax3 ?
> >
> >
> >  
> >
> I shutter at the thought but either way, it's a decision not to be made 
> quite yet. Let's discuss other issues
> 
> AES encryption without RSA encryption: My solution for this was to use 
> the MD5 sum as the key, unfortunately later I realized that brute 
> forcing someone's MD5 isn't that hard. Still much harder than plain 
> text. The way it would work would be the MD5 result would never be sent 
> back but instead used at the key and probably the client would encrypt 
> some other challenge to prove it got it right.
> 
> NEW (with username :|) ->
> AUTHREQ <-  (with MD5 challenge and cipher challenge)
> AUTHREP -> (cipher challenge encrypted by AES using the result of the 
> MD5 sum as the key)
> Asterisk checks the cipher and if correct decrypts the rest of the 
> packet (as all packets now will be encrypted)
> 
> Now yea, there's some issues here: a) transmission of username, but it's 
> needed b) Currently IAX2 transmits the destination number (and other 
> things) in it's NEW, which here would unencrypted.
> 
> Renegotiation of private keys on transfer - Asterisk shouldn't know the 
> private key in the conversation if native transferred. This is quite 
> paramount and I recall John Todd requesting this in some form. Of 
> course, this is impossible without some form of public key exchange (so 
> not when MD5 key is used)
> 
> RSA should be preferred as using it's much stronger than my suggested 
> MD5 method. I think this is more a responsibility for IAX clients to 
> suggest usage of RSA (or in most cases actually allow it for a start)
> 
> I'd love Mark's input
> 
> -Adam
> 
> 
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> 
> 

-- 
Derek Smithies Ph.D.                           This PC runs pine on linux for email
IndraNet Technologies Ltd.                     If you find a virus apparently from me, it has
Email: derek at indranet.co.nz                    forged  the e-mail headers on someone else's machine
ph +64 3 365 6485                              Please do not notify me when (apparently) receiving a
Web: http://www.indranet-technologies.com/     windows virus from me......




More information about the asterisk-dev mailing list