Login
Wiki HomeIAX encryption
As of asterisk version 1.2.4 (maybe before) there is a rather undocumented channel encryption feature included in chan_iax2. After successful authentication the whole channel including control data and voice data is encrypted with AES128. The encryption can be activated by adding the line
encryption=aes128
or
encryption=yes
respectively to your iax.conf. For the encryption to be functional you have to use MD5 authentication since one is based upon the other in this particular implementation!
Note: The calling/called numbers are still passed in the clear over encrypted IAX, so you are still vulnerable to traffic analysis.
If you also 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.
The IAX encryption scheme is documented in the draft RFC at:
http://mirror.switch.ch/ftp/mirror/internet-drafts/draft-guy-iax-03.txt
Example
For example, consider the following scenario:alice (192.168.25.10) <-----> bob (192.168.25.11)
iax.conf on alice:
[bob-enc]
type=friend
host=192.168.25.11
username=alice-enc
auth=md5
secret=foobar
trunk=no
notransfer=no
encryption=aes128
disallow=all
allow=alaw
iax.conf on bob:
[alice-enc]
type=friend
host=192.168.25.10
username=bob-enc
auth=md5
secret=foobar
trunk=no
notransfer=no
encryption=aes128
disallow=all
allow=alaw
Debugging
In order to verify the correct configuration you could use the following CLI command:bob*CLI> iax2 show peers
Name/Username Host Mask Port Status
alice-enc/bob-e 192.168.25.10 (S) 255.255.255.255 4569 (E) Unmonitored
The "(E)" indicates our encryption feature. Unfortunately the "(E)" also appears when using other authentication methods than MD5, however the actual encryption is NOT operational in this case.
If you would like to see the encryption in action, try the debug output in "logger.conf" and issue the following CLI commands:
bob*CLI> set debug 1
Core debug is at least 1
bob*CLI> iax2 debug
IAX2 Debugging Enabled
the debug output of our control data looks like this:
TE-Frame Retry
Timestamp: 20004ms SCall: 00001 DCall: 00004
Feb 15 14:09:22 DEBUG
Feb 15 14:09:22 DEBUG
Tx-Frame Retry
Timestamp: 3945693623ms SCall: 00001 DCall: 00004
Rx-Frame Retry
Timestamp: 43813863ms SCall: 00004 DCall: 00001
Feb 15 14:09:22 DEBUG
RD-Frame Retry
Timestamp: 20001ms SCall: 00004 DCall: 00001
... and the voice data:
Feb 15 14:09:23 DEBUG18288: chan_iax2.c:3891 encrypt_frame: Encoding mini frame with length 164
Feb 15 14:09:23 DEBUG17937: chan_iax2.c:3851 decode_frame: Decoding mini with length 194
Page Changes
VoIP Security Solutions
The core solution for VoIP Security and VoIP anti-blocking is VGCP (VoiceGuard Control Protocol).
It can work with any 3rd-party Softphone / ATA / Gateway / IP Phone / IADs and SIP proxy or server.
It can work in the way similar to that of SOHO router, but it only encrypts and decrypts SIP and RTP packets on link layer, not to handup these packets to IP stack for forwarding while bypassing other data packets originating from SIP terminals. In this scenario, peak throughput and minimal CPU overhead can be easily achieved.
VoiceGuard can real-time incorporate light-weight traffic for puzzling and bypassing VoIP blocking system without consuming more bandwidth and compromising voice quality. Even in some circumstance, VoiceGuard can simulate traffic behavior of universal data networking protocol such as OICQ, MSN and so on.
For more information, please refer to: http://www.speed-voip.com/index-36.html
Andy
xd.wong@speed-voip.com
andywong-01@hotmail.com
Any Updates on IAX encrytption
beware, this is only alpha stage encryption
For the time being neither IAX2 nor this encryption feature is part of any standard which makes both rather unpredictable to sudden changes. And also the following issues are yet to be solved:
- transferring the call and keeping the encryption up and running
- a key challenge based on RSA
- user-based encryption, not just host-based
- signalisation of a secure channel, maybe by setting a variable
- more encryption algorithms
- ... probably more things to do
Besides,... an issue has been raised on the developers mailing list on the security of this particular implementation of channel encryption.
Again, this feature is really nice to have, yet unfinished. There is neither reliability nor security proven. This will probably change in the near future. Until then i suggest to use alternative methods of encryption like IPSec, PPTP, OpenVPN, ... you name it.
Link2VoIP supports the new AES128 encryption
Link2VoIP.com supports the new AES128 encryption on IAX2 channels, when you signup they ask you if you want the option enabled. I have been using it for 2 days now, and it is working. No more sharking my VoIP traffic! :D
Peace!
Link2VoIP supports the new AES128 encryption
Link2VoIP.com supports the new AES128 encryption on IAX2 channels, when you signup they ask you if you want the option enabled. I have been using it for 2 days now, and it is working. No more sharking my VoIP traffic! :D
Peace!
Getting service providers to implement this is next
Why this wasn't big news, I have no idea.