[asterisk-dev] AstriDevCon Recap - IAX2 RENEW for encryption
paul at gccs.co.za
Fri Jun 1 01:35:51 MST 2007
On Thursday 31 May 2007 18:14, Russell Bryant wrote:
> 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.
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 Hewlett Technical Director
Global Call Center Solutions Ltd, 2nd Floor, Milnerton Mall
Cnr Loxton & Koeberg Roads, 7435 Milnerton
Tel: +27 86 111 3433 Fax: +27 86 111 3520 Cel: +27 76 072 7906
Gizmo: 1 747 659 6171
More information about the asterisk-dev