Monday, February 1, 2010

On breaking phonecall encryption and publishing fake research

Recently, some "not so anonymous" security researcher posted research on a website called InfoSecurityGuard. It showed how he had broken the encryption provided by various mobile phone security products. Ofcourse this caught the eyes of various journalists who wrote about this without much consideration. So what did this researcher find out?



The research focuses on the fact that once you get malicious software on a phone, you can listen on the phonecall even with encryption software in place, such as CellCrypt or Gold-Lock. The researcher says that this is a result of these products not having any man in the middle protection.

Well, guess what: the products on test do network encryption. Putting software on the same phone as the one doing the encryption/decryption does not constitute as man in the middle by most definitions. Such products do not typically protect your calls from being recorded if your phone is compromised.

This applies to most other applications, not just phonecall encryption. If your security solution is meant to provide network encryption, then it typically will not resist an attack on the endpoints. Some software (like PhoneCrypt) might try to do that, but in the end of the day, if the endpoint is compromised, then there's various attacks that the software cannot handle.

Think about replacing the firmware, or the hardware itself. These are real problems that apply when your phone is compromised, yet such products are not meant to handle these issues.

After this "fake" research came out, some people actually investigated to confirm the suspicions that they were published by a known vendor - in fact the only vendor that did well in the reviews - Securstar. Read more about that on infosecurity.ch and The Register.

Oh, and one word of advice for anyone replicating Securstar's efforts - do not put your Trixbox PBX with the FOP in the open.

ps. at the time of writing Securstar's site is inaccessible and showing some php errors:

Labels: , , , , , , ,

Friday, February 8, 2008

SIP, TLS and Asterisk 1.6

Until a few weeks ago, to enable TLS support in Asterisk you had to apply patches to the source code. As of version 1.6, Asterisk will have native TLS support for SIP transport, making it one of the few IP PBX systems out there that support this security feature.

Too many experts suggest encryption as a solution to the VoIP confidentiality issues, but in reality the number of PBX and IP phones that support is still very low and many times it is not a viable solution. However, we hope that this might change.

So - is native SRTP support next on the to do list? ;-)


Labels: , , ,

Friday, September 7, 2007

Security Analysis of Voice-over-IP Protocols

This paper talks about the state of security or lack of of the VoIP protocols. It talks a lot about encryption and introduces some attacks in that area. Of interest:
  • replay attack on SDES key exchange causing SRTP to use the same keystream in multiple sessions. This means that the attacker removes encryption from SRTP-protected data streams.
  • An attack on ZRTP involving unauthenticated uesr IDs. This allows bypassing / disabling of authentication or a DoS attack.
  • A security issue related to randomness in MIKEY

Labels: , , , , , , , , , , ,