Tap here to compare the top VoIP providersTap here to hide the top VoIP Providers
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
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.
However, 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.
Asterisk 1.4.24 (and 1.6.1.x): Bug 14607 fixed two rather important issues, one of them causing a hang up on an encrypted IAX2 conversation in case of packet loss; moreover the random padding of the encrypted payload was not as random as one would like it to be...
The IAX encryption scheme is documented in the draft RFC at:
Asterisk 1.6.1.x: IAX2 encryption support has been improved to support periodic key rotation within a call for enhanced security. The option "keyrotate" has been provided to disable this functionality to preserve backwards compatibility with older versions of IAX2 that do not support key rotation.
ExampleFor example, consider the following scenario:
alice (192.168.25.10) <-----> bob (192.168.25.11)
iax.conf on alice:
iax.conf on bob:
DebuggingIn 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 -- OSeqno: 009 ISeqno: 009 Type: IAX Subclass: LAGRP Timestamp: 20004ms SCall: 00001 DCall: 00004 [192.168.25.10:4569] Feb 15 14:09:22 DEBUG: chan_iax2.c:3875 encrypt_frame: Encoding full frame 6/12 with length 12 Feb 15 14:09:22 DEBUG: chan_iax2.c:3883 encrypt_frame: Encoding full frame 6/12 with length 12 + 24 padding (15=28) Tx-Frame Retry -- OSeqno: 017 ISeqno: 002 Type: (168?) Subclass: 141 Timestamp: 3945693623ms SCall: 00001 DCall: 00004 [192.168.25.10:4569] Rx-Frame Retry[ No] -- OSeqno: 133 ISeqno: 235 Type: (132?) Subclass: 101 Timestamp: 43813863ms SCall: 00004 DCall: 00001 [192.168.25.10:4569] Feb 15 14:09:22 DEBUG: chan_iax2.c:3836 decode_frame: Decoding full frame with length 36 (padding = 24) (15=d8) RD-Frame Retry[ No] -- OSeqno: 008 ISeqno: 009 Type: IAX Subclass: ACK Timestamp: 20001ms SCall: 00004 DCall: 00001 [192.168.25.10:4569]
... and the voice data:
Feb 15 14:09:23 DEBUG: chan_iax2.c:3891 encrypt_frame: Encoding mini frame with length 164 Feb 15 14:09:23 DEBUG: chan_iax2.c:3851 decode_frame: Decoding mini with length 194
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+