[Asterisk-Dev] IAX2 encryption

[Derek Smithies]

Hi,

I am a little concerned about the encryption algorithm in IAX2.
It appears to use more bytes than needed, and should access methods in the 
openssl library. 

Please let me explain.


A while ago, Brian West announced on this list that the Opal library 
includes a C++ MPL version of the IAX2 protocol.

http://lists.digium.com/pipermail/asterisk-dev/2005-August/014416.html

Since then, Adrian Sietsma has written some good patches, and he reports
that the code compiles fine under MSVC and runs in windows. Thanks Adrian.

Since then I have added security to the codebase, following the protocol 
layed out in the CVS-Head. Brian West supplied an asterisk endpoint (with 
security) for me to call to test the code. Thanks Brian.

The encryption process is
split the packet into two halves, where the first half contains the source 
and dest call number (or just source call number for mini packets).

place the first half into the resultant packet
place a 16 byte buffer into the resultant packet.
place some padding  plus the second half of the packet into the resultant 
packet.

the padding is of a size such that the sizeof the padding + second half 
is an integer multiple of 16 bytes.

The last byte of the 16 byte buffer contains the size of the padding.

The resultant packet is encrypted with a call to AES_decrypt(src, dst,
key) from the openssl library. Note that only the 16byte buffer, the
padding, and the second half are encrypted. The source/dest call numbers
are left in the clear. In asterisk, the packet is encrypted with a call to 
memcpy_encrypt, which calls routines that are identical to those in 
openssl.

The key is generated from a 16 byte long string, which is derived from MD5 
hashing of the password and challenge. The 16 byte long string is derived 
in the same way that the IAX_IE_MD5_RESULT is generated.

Prior to encrypting the packet, a bitwise XOR is applied to the source 
data.


The decryption is the reverse.

There are some things I do not (as yet) understand, and I am hoping that 
someone can explain.

*I do not see the need for the 16 byte buffer. Earlier versions of the 
CVS-head read the padding length from the 16 byte region before 
decryption. As though the intent was to store the padding size in this 
block after encryption, which renders any underlying data in this 16 byte 
block useless.

*I was surprised to see a copy of the AES encryption code in the * 
codebase, when it already exists in the openssl library. I thought this 
was the whole purpose of libraries - use the code in the library and have 
less to compile & maintain.

*The bitwise XOR that is applied to the data - why is this needed?
 However, there are several examples in the openssl source where they do 
 bitwise XORs prior to calling AES_encrypt - so is probably OK.


Thanks in advance for any suggestions.

 Derek.

 -- 
Derek Smithies Ph.D.                 Any fool can write code that 
IndraNet Technologies Ltd.                a computer can understand.        
Email: derek at indranet.co.nz         Good programmers write code 
ph +64 3 365 6485                          that humans can understand.
Web: http://www.indranet-technologies.com/            Martin Fowler