[Asterisk-Security] IAX encryption

[Enzo Michelangeli]

Hello everybody,

Has anybody in the security community reviewed the design of teh cptioned
matter? Cryptography, and security in general, present a lot of tricky
pitfalls, and it would be good to have possible flaws found and fixed
before an official release. Even cryptosystrems designed by competent
people (including SSL, SSH, PGP itself) presented embarrassing weaknesses
in their first incarnation. I'm a bit worried by the existence of working
code _before_ written specs...

If, on the other hand, such specifications do exist, I would recommend to
make a public announcement (e.g., posting a message to
cryptography at metzdowd.com) and invite feedback _before_ the actual
deployment on the field.

Meanwhile, I had to settle for glance at the source code, which did little
to reassure me. From what I can understand, the actual data is
encrypted/decrypted with AES128, using a session key derived from local
secret and remotely-provided challenge through a simple MD5 hash:

--------------- 8< --------------- 
static void build_enc_keys(const unsigned char *digest, aes_encrypt_ctx
*ecx, aes_decrypt_ctx *dcx)
{
 aes_encrypt_key128(digest, ecx);
 aes_decrypt_key128(digest, dcx);
}

[...]

static int decrypt_frame(int callno, struct ast_iax2_full_hdr *fh, struct
ast_frame *f, int *datalen)
{
 int res=-1;
 if (!ast_test_flag(iaxs[callno], IAX_KEYPOPULATED)) {
  /* Search for possible keys, given secrets */
  struct MD5Context md5;
  unsigned char digest[16];
  char *tmppw, *stringp;

  tmppw = ast_strdupa(iaxs[callno]->secret);
  stringp = tmppw;
  while((tmppw = strsep(&stringp, ";"))) {
   MD5Init(&md5);
   MD5Update(&md5, iaxs[callno]->challenge,
             strlen(iaxs[callno]->challenge));
   MD5Update(&md5, tmppw, strlen(tmppw));
   MD5Final(digest, &md5);
   build_enc_keys(digest, &iaxs[callno]->ecx, &iaxs[callno]->dcx);
   res = decode_frame(&iaxs[callno]->dcx, fh, f, datalen);
   if (!res) {
    ast_set_flag(iaxs[callno], IAX_KEYPOPULATED);
    break;
   }
  }
 } else
  res = decode_frame(&iaxs[callno]->dcx, fh, f, datalen);
 return res;
}
--------------- 8< --------------- 

Now, this is a non-salted, non-iterated key derivation, vulnerable
to bruteforce attacks (see e.g.
http://en.wikipedia.org/wiki/Key_derivation_function ); and the challenge,
I guess, is provided by the counterpart, which may be untrusted and might
be choosing it in a way to make the attacks easier. On top of that, MD5
is now regarded with suspicion (especially for non-HMAC applications) due
to
to weaknesses found in it, particularly last year. Finally, the key
derivation seems to be performed every time a frame has to be decoded,
which doesn't really appear to be efficient.

Am I missing something? If so, could someone shed light and correct me?

Enzo

-----------------------------------------------
Brian Capouch brianc at palaver.net
Sun Aug 7 13:48:41 CDT 2005

Fabio Pietrosanti wrote:
> Brian Capouch ha scritto:
>
>
>>IAX encryption has been working for over a month now.  I am not
>>qualified to audit it, but as far as "workability" I haven't
>>encountered any major problems.
>
>
> Great! Could you point out some documentation about the design and/or
> functionality and/or configuration?
> I would be glad to propose it to opensource audit community on other
> mailing lists

It is essentially undocumented, which of course is a big problem.

I'm not qualified to do it, by the way.

Basically it's an automatic features (CVS-HEAD only, btw) where anytime
a pair of IAX peers have encryption set to "yes" (or, as I understand
it, a mutually-agreed-upon and supported algorithm) then it just happens
automagically.

The code is in the various files that govern IAX in ~/channels.

B.