[asterisk-dev] AstriDevCon Recap - IAX2 RENEW for encryption

[Paul Hewlett]

On Thursday 31 May 2007 18:14, Russell Bryant wrote:
> Greetings,
>
> One of the topics discussed at the developer conference was the method
> used for IAX2 encryption.  We wanted to ensure that the method we are
> using is actually secure.  I have summarized what came out of the
> discussion below.  Comments are welcome, as always.
>
>  From this discussion, we need to make two changes.  One is an
> implementation issue, and the other is a protocol level issue.  The
> protocol level issue needs to get resolved quickly so that we can get it
> in the first version of the RFC, since IAX2 encryption is in there.
>
> 1) We should use a better random number generator.  Most of the places
> in Asterisk are using the ast_random() wrapper, so changing the method
> in one place should affect every usage.
>
> Currently, we use random(), which is better than rand(), but we seed it
> with the process ID and time.  We should just change the code to open
> and read from /dev/urandom where it is available.

If I can add 2c here. I had an interesting experience on a headless PC running 
Gentoo Linux - when apache started the machine hung forever waiting on a read 
from /dev/random. The only way to make the PC continue with the boot process 
was to plug a keyboard in and hit as many different keys as possible.

The reason for this strange behaviour is that the entropy of the random device 
was too low and the read had blocked. Entropy in the RNG is obtained from the 
keyboard, mouse, IDE disk and until recently the ethernet device. The 
ethernet device was removed from the entropy list in recent kernels for 
perceived security reasons - this means that headless devices have poor 
characteristics. To solve this it is tempting to read from /dev/urandom 
instead which never blocks. However arguably this makes things worse as one 
would then be under the impression that this is a better solution when in 
fact it is actually worse than the pre-seeded pseudo-random number generator. 

http://www.number.ch/wiki/index.php/LinuxEntropySources
http://linuxfromscratch.org/pipermail/hints/2004-November/002716.html

This leads to a question for the zaptel driver developers :

Have you considered adding SA_SAMPLE_RANDOM to the arguments of the 
request_irq() call in the drivers ? This would add the zaptel drivers to list 
of devices that contribute to the entropy pool and theoretically at least 
increase security. Or are the interrupts generated by zaptel devices too 
regular or unsuitable for this purpose ?

Paul


-- 
Paul Hewlett  Technical Director 
Global Call Center Solutions Ltd, 2nd Floor, Milnerton Mall
Cnr Loxton & Koeberg Roads, 7435 Milnerton
www.gccs.co.za
Tel: +27 86 111 3433 Fax: +27 86 111 3520 Cel: +27 76 072 7906
Gizmo: 1 747 659 6171