Tag Archives: zrtp

RFC 6189: ZRTP is finally a standard!

Finally ZRTP has been assigned an official RFC assignment, RFC6189 ZRTP: Media Path Key Agreement for Unicast Secure RTP.

It had as a dependency the SRTP with AES key size of 256bit that now has been defined as RFC6188.

It’s exciting to see the RFC finally released, as it’s an important milestone to set ZRTP as the official standard for end-to-end encryption much like PGP has been for emails.

Now any organization in the world will be officially able to implement ZRTP for end-to-end protocol voice encryption

Currently 3 different public implementations of ZRTP protocol exists:

Each of them provide different features of the protocol, but most important are known to be interoperable.

A new wave is coming to the voice encryption world, irrupting into a gray area where most of the companies doing phone encryption systems has been implementing custom encryption.

Now a standard has been setup and there are few reasons left to implementing something different.

Hurra Mr. Zimmermann and all the community of companies (like PrivateWave) and individuals (like Werner Dittmann) that worked on it!

Today it’s a great day, such kind of technology is now official and also with multiple existing implementation!

Philip, you did it again, my compliments to your pure spirit and determination :-)

ZORG, new C++ and Java ZRTP implementation public release

Hi all, today at PrivateWave Italia S.p.A, italian company engaged in developing technologies for privacy protection and information security in voice telecommunications where i am CTO, we release ZORG, a new open source ZRTP protocol implementation available for download from http://www.zrtp.org .

ZRTP [1] provides end-to-end key exchange with Elliptic Curve Diffie-Hellmann 384bit and AES-256 SRTP encryption .

ZORG has been originally developed and implemented in PrivateWave’s PrivateGSM voice encryption products available for the following platforms: Blackberry, Nokia and iOS (iPhone) .

Zorg C++ has been integrated with PJSIP open source VoIP SDK [2] and it’s provided as integration patch against PJSIP 1.8.5. It has been tested on iPhone, Symbian, Windows, Linux and Mac OS X.

Zorg Java has been integrated within a custom version of MJSIP [3] open source SDK on Blackberry platform and it includes memory usage optimizations required to reduce at minimum garbage collector activity.

Both platforms have separated and modular cryptographic back-ends so that the cryptographic algorithms implementation could be easily swapped with other ones.

ZORG is licensed under GNU AGPL and source code is available on github at https://github.com/privatewave/ZORG .

We are releasing it under open source and in coherence with our approach to security [4] as we really hope that it can be useful for the open source ecosystem to create new voice encryption systems in support of freedom of speech.

More than 20 pjsip-based open source VoIP encryption software and several written in Java could directly benefit from ZORG release.

We would be happy to receive proposal of cooperation, new integration, new cryptographic back-ends, bug scouting and whatever useful to improve and let ZRTP affirm as voice encryption standard.

Zorg is available from http://www.zrtp.org .

[1] ZRTP: http://en.wikipedia.org/wiki/ZRTP
[2] PJSIP: http://www.pjsip.org
[3] MJSIP: http://www.mjsip.org
[4] Security approach: http://www.privatewave.com/security/approch.html

PrivateGSM: Blackberry/iPhone/Nokia mobile voice encryption with ZRTP or SRTP/SDES

I absolutely avoid to use my own personal blog to make promotion of any kind of product.

That time it’s not different, but i want to tell you facts about products i work on without fancy marketing, but staying technical.

Today, at PrivateWave where i am CTO and co-founder, we released publicly mobile VoIP encryption products for Blackberry, iPhone and Nokia:

  • The 1st ever Blackberry encrypted VoIP with ZRTP - PrivateGSM VoIP Professional
  • The 1st ever iPhone encrypted VoIP with ZRTP - PrivateGSM VoIP Professional
  • The 1st ever Blackberry encrypted VoIP client with SRTP with SDES key exchange over SIP/TLS - PrivateGSM VoIP Enterprise


At PrivateWave we use a different approach respect to most voice encryption company out there, read our approach to security .

The relevance of this products in the technology and industry landscape can be summarized as follow:

  • It’s the first voice encryption company using only standards security protocols (and we expect the market will react, as it’s clear that proprietary tech coming from the heritage of CSD cannot provide same value)
  • It’s the first approach in voice encryption to use only open source & standard encryption engine
  • It’s the first voice encryption approach to provide different security model using different technologies (end-to-end for ZRTP and end-to-site for SRTP)

Those suite of Mobile Secure Clients, designed for professional security use only using best telecommunication and security technologies, provide a high degree of protection along with good performance also in bad network conditions:

The applications are:


The supported mobile devices are:

Regarding ZRTP we decided to stress and stretch all the security and paranoid feature of the protocol with some little addition:

Our strict address book integration, goes beyond ZRTP RFC specification, that could be vulnerable to certain attacks when used on mobile phones because of user behavior of not to look at mobile screen.

Our paranoy way of using ZRTP mitigate such conditions, we will write about this later and/or will add specific details for RFC inclusion.

Some words on PrivateGSM Professional with end-to-end encryption with ZRTP

Read technical sheet there!

To download it click here and just put your phone number

Those are the results of hard work of all my very skilled staff (16 persons worked on this 6 projects for 3 different platforms) on challenging technologies (voice encryption) in a difficult operating environment (dirty mobile networks and dirty mobile operating systems) for more than 2 years.

I am very proud of our staff!

What next?

In next weeks you will see releasing of major set of documentations such as integration with asterisks, freeswitch and other Security Enabled PBX, along with some exciting other security technology news that i am sure will be noticed ;)

It has been an hard work and more have to be done but i am confident that the security and opensource community will like such products and our transparent approach also with open important releases and open source integration that make a very politically neutral (backdoor free) technology.

Not every elliptic curve is the same: trough on ECC security

My own ECC curve security and selection analysis


Most modern crypto use Elliptic Curve Cryptographic (ECC) that, with a smaller key size and reduce computation power, give equivalent security strength of traditional crypto system known as DH (Diffie-Hellman) or RSA (Rivest, Shamir and Adleman) .

Not everyone knows that ECC encryption is selected for any future encryption applications and that even TLS/SSL (encryption used for securing the web) is moving to ECC.

I found plenty of so called “proprietary encryption products” which abandoned RSA and DH to goes with ECC alternatives, that tend to arbitrary use ECC bit key size without even specifying which kind of ECC crypto get used.

However there is a lot of confusion around Elliptic Curves, with a lot of different names and key size making difficult for a non-cryptographically-experienced-user to make your own figure when evaluating some crypto stuff.

Because of so diffused confusion i decided to make my own analysis to find out which are the best ECC encryption curves and right ECC key size to use.

This analysis would like to provide a security industry based choice among various curves and key sizes, leaving the mathematical and crypto analytical considerations that has been already been done during the years, summarizing the various choices taken in several standards and security protocols.

First the conclusion.

From my analysis only the following ECC curves are to be considered for use in encryption systems because are the only one selected among different authorities (ANSI, NSA, SAG, NIST, ECC BrainPool), different security protocol standards (IPSec, OpenPGP, ZRTP, Kerberos, SSL/TLS) and the only one matching NSA Suite B security requirements (de-facto standard also for NATO military environment):

  • Elliptic Prime Curve 256 bit - P-256
  • Elliptic Prime Curve 384 bit - P-384

with optional, just for really paranoid that want to get more key size bit, still not considered useful:

  • Elliptic Prime Curve 521 bit - P-521

I would like to state that Koblitz curves should be avoided, in any key size (163 / 283 / 409 / 571) as they does not have enough warranty on crypto analytic activity and effectively they are:

  • Not part of NSA Suite-B cryptography selection
  • Not part of ECC Brainpool selection
  • Not part of ANSI X9.62 selection
  • Not part of OpenPGP ECC extension selection
  • Not part of Kerberos extension for ECC curve selection

I invite the reader to follow trough my analysis to understand the fundamentals that could be understood even without deep technical background but at least with a good technological background a some basic bit of cryptography.

Here we go with the analysis


My goal is to make an analysis on what/how the open scientific and security community choose ECC crypto system for usage in security protocols and standards defined by IETF RFC (the ones who define Internet Standards in a open and peer-reviewed way).

Below a set of RFC introducing ECC into existing system that get analyzed to understand what’s better to use and what’s better to exclude:

  • RFC5639: ECC Brainpool Standard Curves & Curve Generation
  • RFC4869: NSA Suite B Cryptographic Suites for IPsec
  • RFC5430: NSA Suite B profile for Transport Layer Security (TLS)
  • RFC5008: NSA Suite B in in Secure/Multipurpose Internet Mail Extensions (S/MIME)
  • RFC3766: Determining Strengths For Public Keys Used For Exchanging Symmetric Keys
  • RFC5349: Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
  • RFC4492: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
  • ZRTP voice encryption by Philip Zimmermann ECC curve
  • ECC in OpenPGP (draft draft-jivsov-openpgp-ecc-06)
  • ECC Curves selected by Microsoft for Smartcard Kerberos login

We will use the choice made by scientist defining Internet Security Protocols to make part of our evaluation.
Additionally it must be understood that the Curve selection comes from different authorities that made their own selection of Curves in order to tell to the industry what to use and what to skip:

We will use the choice made by scientist defining security requirements in the standardization agencies to make part of our evaluation.
Additionally, something that most people does not know, but that it’s extremely relevant to our analysis, is that there are different kind of ECC curve cryptography and their “size” it’s different depending on the kind of curve:

  • ECC Curves over Prime Field (often referred as Elliptic Curve and represented by P-keysize)
  • ECC Curves over Binary Field (often referred as Koblitz Curve and represented by K-keysize)

Given a security strength equivalence the Elliptic Curve and the Kobliz Curve have different key size, for example when we read ECC 571 we are referring to Koblitz Curve with an equivalent strength to ECC 521 Prime curve.

A comparison of strength between Elliptic Curves and Kotbliz Curves is reported below (from Mikey ECC internet Draft):

| Koblitz |  ECC  |  DH/DSA/RSA
|   163   |  192  |     1024
|   283   |  256  |     3072
|   409   |  384  |     7680
|   571   |  521  |    15360

Below there’s a comparison of all selected curves by all the various entities and their respective name (from IETF RFC4492 for ECC usage for TLS) :

Curve names chosen by different standards organizations
SECG        |  ANSI X9.62   |  NIST
sect163k1   |               |   NIST K-163
sect163r1   |               |
sect163r2   |               |   NIST B-163
sect193r1   |               |
sect193r2   |               |
sect233k1   |               |   NIST K-233
sect233r1   |               |   NIST B-233
sect239k1   |               |
sect283k1   |               |   NIST K-283
sect283r1   |               |   NIST B-283
sect409k1   |               |   NIST K-409
sect409r1   |               |   NIST B-409
sect571k1   |               |   NIST K-571
sect571r1   |               |   NIST B-571
secp160k1   |               |
secp160r1   |               |
secp160r2   |               |
secp192k1   |               |
secp192r1   |  prime192v1   |   NIST P-192
secp224k1   |               |
secp224r1   |               |   NIST P-224
secp256k1   |               |
secp256r1   |  prime256v1   |   NIST P-256
secp384r1   |               |   NIST P-384
secp521r1   |               |   NIST P-521

What immediately appear is that there are only two curves selected by all authorities, and that there is a general dumping of koblitz curves by ANSI.The only commonly agreed among the 3 authorities are the following two ECC curve:

  • secp192r1 / prime192v1 / NIST P-192
  • secp256r1 / prime256v1 / NIST P-256

Of those selection of ECC curve for TLS the RFC5430 skipped completely koblitz curves and selected for usage only:

  • P-256, P-384, P-521

The ECC Brainpool skipped completely Koblitz curves and selected for usage the following ECC Curves:

  • P-160, P-192, P-224, P-256, P-320, P-384, P-512 (that’s the only particular because it’s not P-521 but P-512, the only key-size referred by ECC brainpool. Tnx Ian Simons from Athena SCS)

The OpenPGP internet draft for ECC usage in PGP draft-jivsov-openpgp-ecc-06 skipped completely Koblitz curves and selected the following ECC curves

  • P-256, P-384, P-521

The Kerberos protocol extension for ECC use, defined in RFC5349 and defined by Microsoft for smartcard logon skipped completely Koblitz curves and selected the following ECC curves:

  • P-256, P-384, P-521

So, sounds clear that the right selection of ECC is for P-256, P-384 and P-521 while the Koblitz curve have been skipped for Top Secret use and for any security sensitive protocol (IPSec, OpenPGP, ZRTP, Kerberos, SSL/TLS).

Why i made this analysis?

I have done this analysis following a discussion i had regarding certain voice encryption products, all based on custom and proprietary protocols, that are all using Elliptic Curve Diffie Hellman 571 bit / ECDH 571 / 571-bit ECDH / Koblitz 571 bits .
All them are using the K-571 that, as described before, has been removed from all security sensitive environment and protocols and being myself a designer of voice encryption stuff i think that their cryptographic choice is absolutely not the best security choice.
Probably it has been done just for marketing purpose, because K-571 (Koblitz curve) seems stronger than P-521 (Elliptic curve based on Prime number). If you have “more bit” your marketing guys can claim to be “more secure”. Koblitz elliptic curve are faster than the top secret enabled prime elliptic curve and so give the product manager a chance to provide “more bit” in it’s own product while keeping the key exchange fast.

It’s a matter of philosophical choice.

I prefer to follow the trend of scientific community with the humility of not to considering myself a cryptographic expert, knowledgable more than the overall security and scientific community itself.

I prefer instead to use only algorithms that are approved for use in highly sensitive environments (top secret classification), that have been selected by all the authorities and working group analyzing encryption algorithms existing out-there and that represent the choice of almost all standard security protocols (IPSec, OpenPGP, ZRTP, Kerberos, SSL/TLS, etc).
I prefer to count the amount of brains working on the crypto i use, that check that’s really secure, that evaluate whether there’s some weakness.

The number of brais working on Crypto widely diffused are of order of magnitude more than the number of brains working on crypto used by just few people (like Koblitz curve).
So i am not demonizing who use ECDH 571 using Koblitz Curve, but for sure i can affirm that they did not taken the best choice in terms of security and that any security professionals doing a security benchmarking would consider the fact that Elliptic Curve Diffie Hellman 571 bit done with Koblitz Curve is not widely diffused, it’s dumped from standard security protocols and it’s not certified for top secret use.

Mobile Security talk at WHYMCA conference

I want to share some slides i used to talk about mobile security at whymca mobile conference in Milan.

Read here my slides on mobile security .

The slides provide a wide an in-depth overview of mobile security related matters, i should be doing some slidecast about it putting also audio. Maybe will do, maybe not, it depends on time that’s always a insufficient resource.

Quantum cryptography broken

Quantum cryptography it’s something very challenging, encryption methods that leverage the law of phisycs to secure communications over fiber lines.

To oversimplify the system is based on the fact that if someone cut the fiber, put a tap in the middle, and joint together the other side of the fiber, the amount of “errors” that will be on the communications path will be higher than 20% .

So if QBER (Quantum Bit Error Rate) goes above 20% then it’s assumed that the system is intercepted.

Researcher at university of toronto was able to cheat the system with a staying below the 20%, at 19.7% , thus tweaking the threshold used by the system to consider the communication channel secure vs compromised.

The product found vulnerable is called Cerberis Layer2 and produced by the Swiss ID Quantique.

Some possibile approach to detect the attack has been provided but probably, imho, such kind of systems does not have to be considered 100% reliable until the technology will be mature enough.

Traditional encryption has to be used together till several years, eventually bundled with quantum encryption whether applicable.

When we will see a quantum encryption systems on an RFC like we have seen for ZRTP, PGP and SSL ?


Encryption is not scrambling: be aware of scrambler!

Most of us know about voice scrambler that can be used across almost any kind of voice based communication technology.

Extremely flexible approach: works everything

Extreme performance: very low latency

but unfortunately…

Extremely weak: Scrambling cannot be considered secure.

Only encryption can be considered secure under the Kerckoff’s principle .

So please don’t even consider any kind of analog scrambler if you need real security.

Read deeply the paper Implementation of a real-time voice encryption system” by Markus Brandau, especially the cryptoanalysis paragraph.

About the SecurStar GmbH Phonecrypt voice encryption analysis (criteria, errors and different results)

This article want to clarify and better explain the finding at infosecurityguard.com regaring voice encryption product evaluation.
This article want to tell you a different point of view other than infosecurityguard.com and explaining which are the rational with extensive explaination from security point of view.
Today i read news saying: “PhoneCrypt: Basic Vulnerability Found in 12 out of 15 Voice Encryption Products and went to read the website infosecurityguard.

Initially it appeared to my like a great research activity but then i started reading deeply the read about it.I found that it’s not properly a security research but there is are concrete elements that’s a marketing campaign well done in order to attract public media and publicize a product.
Imho they was able to cheat journalists and users because the marketing campaign was absolutely well done not to be discovered on 1st read attempt. I personally considered it like a valid one on 1st ready (they cheated me initially!).

But if you go deeply… you will understand that:
- it’s a camouflage marketing initiative arranged by SecurStar GmbH and not a independent security research
- they consider a only security context where local device has been compromised (no software can be secured in that case, like saying SSL can be compromised if you have a trojan!)
- they do not consider any basic security and cryptographic security criteria

However a lot of important website reported it:

This article is quite long, if you read it you will understand better what’s going on around infosecurityguard.com research and research result.

I want to to tell you why and how (imho) they are wrong.

The research missed to consider Security, Cryptography and Transparency!

Well, all this research sound much like being focused on the marketing goal to say that their PhoneCrypt product is the “super” product best of all the other ones.
Any security expert that would have as duty the “software evaluation” in order to protect the confidentiality of phone calls will evaluate other different characteristics of the product and the technology.

Yes, it’s true that most of the product described by SecurStar in their anonymous marketing website called http://infosecurityguard.com have some weakness.
But the relevant weakness are others and PhoneCrypt unfortunately, like most of the described products suffer from this.
Let’s review which characteristics are needed basic cryptography and security requirement (the best practice, the foundation and the basics!)

a - Security Trough Obscurity does not work

A basic rule in cryptography cames from 1883 by Auguste Kerckhoffs:

In a well-designed cryptographic system, only the key needs to be secret; there should be no secrecy in the algorithm.
Modern cryptographers have embraced this principle, calling anything else “security by obscurity.”
Read what Bruce Schneir, recognized expert and cryptographer in the world say about this
Any security expert will tell you that’s true. Even a novice university student will tell you that’s true. Simply because that’s the only way to do cryptography.
Almost all product described in the review by SecurStar GmbH, include PhoneCrypt, does not provide precise details about their cryptographic technologies.
Precise details are:
  • Detailed specification of cryptographic algorithm (that’s not just saying “we use AES“)
  • Detailed specification of cryptographic protocol (that’s not just saying “we use Diffie Hellman” )
  • Detailed specification of measuring the cryptographic strenght (that’s not just saying “we have 10000000 bit key size“)

Providing precise details means having extensive documentation with theoretical and practical implications documenting ANY single way of how the algorithm works, how the protocol works with precise specification to replicate it for interoperability testing.
It means that scientific community should be able to play with the technology, audit it, hack it.
If we don’t know anything about the cryptographic system in details, how can we know which are the weakness and strength points?

Mike Fratto, Site editor of Network Computing, made a great article on “Saying NO to proprietary cryptographic systems” .
Cerias Purdue University tell this.

b - NON peer reviewed and NON scientifically approved Cryptography does not work

In any case and in any condition you do cryptography you need to be sure that someone else will check, review, analyze, distruct and reconstract from scratch your technology and provide those information free to the public for open discussion.
That’s exactly how AES was born and like US National Institute of Standard make crypto does (with public contest with public peer review where only the best evaluated win).
A public discussion with a public contest where the a lot of review by most famous and expert cryptographer in the world, hackers (with their name,surname and face, not like Notrax) provide their contribution, tell what they thinks.
That’s called “peer review”.

If a cryptographic technology has an extended and important peer review, distributed in the world coming from universities, private security companies, military institutions, hackers and all coming from different part of the world (from USA to Europe to Russia to South America to Middle east to China) and all of them agree that a specific technology it’s secure…
Well, in that case we can consider the technology secure because a lot of entities with good reputation and authority coming from a lot of different place in the world have publicly reviewed, analyzed and confirmed that a technology it’s secure.

How a private company can even think to invent on it’s own a secure communication protocol when it’s scientifically stated that it’s not possible to do it in a “proprietary and closed way” ?
IBM tell you that peer review it’s required for cryptography.
Bruce Schneier tell you that “Good cryptographers know that nothing substitutes for extensive peer review and years of analysis.”
Philip Zimmermann will tell you to beware of Snake Oil where the story is: “Every software engineer fancies himself a cryptographer, which has led to the proliferation of really bad crypto software.”

c - Closed source cryptography does not work

As you know any kind of “serious” and with “good reputation” cryptographic technology is implemented in opensource.
There are usually multiple implementation of the same cryptographic algorithm and cryptographic protocol to be able to review all the way it works and certify the interoperability.
Supposing to use a standard with precise and extended details on “how it works”, that has been “peer reviewed” by the scientific community BUT that has been re-implemented from scratch by a not so smart programmer and the implementation it’s plenty of bugs.

Well, if the implementation is “opensource” this means that it can be reviewed, improved, tested, audited and the end user will certaintly have in it’s own had a piece of technology “that works safely” .

Google release opensource crypto toolkit
Mozilla release opensource crypto toolkit
Bruce Schneier tell you that Cryptography must be opensource.

Another cryptographic point of view

I don’t want to convince anyone but just provide facts related to science, related to cryptography and security in order to reduce the effect of misinformation done by security companies whose only goes is to sell you something and not to do something that make the world a better.

When you do secure products, if they are not done following the proper approach people could die.
It’s absolutely something irresponsible not to use best practice to do crypto stuff.

To summarize let’s review the infosecurityguard.com review from a security best pratice point of view.

Product name Security Trough Obscurity Public peer review Open Source Compromise locally?
Caspertec Obscurity No public review Closed Yes
CellCrypt Obscurity
No public review
Cryptophone Transparency Limited public review Public Yes
Gold-Lock Obscurity
No public review
Illix Obscurity
No public review
No1.BC Obscurity No public review
PhoneCrypt Obscurity
No public review
Rode&Swarz Obscurity
No public review
Secure-Voice Obscurity
No public review
SecuSmart Obscurity
No public review
SecVoice Obscurity
No public review
SegureGSM Obscurity
No public review
SnapCell Obscurity
No public review
Tripleton Obscurity
No public review
Zfone Transparency Public review
Open Yes
ZRTP Transparency Public review
Open Yes

*Green means that it match basic requirement for a cryptographic secure system

* Red / Broken means that it does not match basic requirement for a cryptographic secure system
That’s my analysis using a evaluation method based on cryptographic and security parameters not including the local compromise context that i consider useless.

However, to be clear, those are only basic parameters to be used when considering a voice encryption product (just to avoid being in a situation that appears like i am promoting other products). So it may absolutely possible that a product with good crypto (transparency, peer reviewed and opensource) is absolutely a not secure product because of whatever reason (badly written, not usable causing user not to use it and use cleartext calls, politically compromised, etc, etc).
I think i will prepare a broader criteria for voice crypto technologies and voice crypto products, so it would be much easier and much practical to have a full transparent set of criterias to evaluate it.

But those are really the basis of security to be matched for a good voice encryption system!
Read some useful past slides on security protocols used in voice encryption systems (2nd part).

Now read below some more practical doubt about their research.

The security concept of the review is misleading: any hacked device can be always intercepted!


Now they are pointing out that also Zfone from Philip Zimmermann is broken (a pc software), just because they install a trojan on a PC like in a mobile phone?
Any security software rely on the fact that the underlying operating system is somehow trusted and preserve the integrity of the environment where the software run.

  • If you have a disk encryption system but your PC if infected by a trojan, the computer is already compromised.
  • If you have a voice encryption system but your PC is infected by a trojan, the computer is already compromised.
  • If you have a voice encryption system but your mobile phone is infected by a trojan, the mobile phone is already compromised.

No matter which software you are running, in such case the security of your operating environment is compromised and in one way or another way all the information integrity and confidentiality is compromised.

Like i explained above how to intercept PhoneCrypt.

The only things that can protect you from this threat is running in a closed operating system with Trust Computing capability, implementing it properly.
For sure on any “Open” operating system such us Windows, Windows Mobile, Linux, iPhone or Android there’s no chance to really protect a software.
On difficult operating system such as Symbian OS or RimOS maybe the running software can be protected (at least partially)

That’s the reason for which the security concept that guys are leveraging to carry on their marketing campaign has no clue.
It’s just because they control the environment, they know Flexispy software and so they adjusted their software not to be interceptable when Flexispy is installed.
If you develop a trojan with the other techniques i described above you will 100% intercept PhoneCrypt.

On that subject also Dustin Tammel, Security researcher of BreakPoint Systems, pointed on on VoIP Security Alliance mailing lists that the security analysis is based on wrong concepts.

The PhoneCrypt can be intercepted: it’s just that they don’t wanted to tell you!

PhoneCrypt can be intercepted with “on device spyware”.
Because Windows Mobile is an unsecure operating environment and PhoneCrypt runs on Windows Mobile.
Windows Mobile does not use Trusted Computing and so any software can do anything.
The platform choice for a secure telephony system is important.
I quickly discussed with some knowledgeable windows mobile hackers about 2 different way to intercept PhoneCrypt with an on-device spyware (given the unsecure Windows Mobile Platform).

a) Inject a malicious DLL into the software and intercept from within the Phonecrypt itself.
In Windows Mobile any software can be subject to DLL code injection.
What an attacker can do is to inject into the PhoneCrypt software (or any software running on the phone), hooking the Audio related functions acting as a “function proxy” between the PhoneCrypt and the real API to record/play audio.
It’s a matter of “hooking” only 2 functions, the one that record and the one that play audio.
Read the official Microsoft documentation on how to do DLL injection on Windows Mobile processes. or forum discussing the technique of injecting DLL on windows mobile processes.
That’s simple, any programmer will tell you to do so.
They simply decided that’s better not to make any notice about this.
b) Create a new audio driver that simply act as a proxy to the real one and intercept PhoneCrypt
In Windows Mobile you can create new Audio Drivers and new Audio Filters.
What an attacker can do is to load a new audio driver that does not do anything else than passing the real audio driver function TO/FROM the realone. In the meantime intercept everything recorded and everything played :-)
Here there is an example on how to do Audio driver for Windows Mobile .
Here a software that implement what i explain here for Windows “Virtual Audio Cable” .
The very same concept apply to Windows Mobile. Check the book “Mobile Malware Attack and Defense” at that link explaining techniques to play with those techniques.
They simply decided that’s better not to make any notice to that way of intercepting phone call on PhoneCrypt .
Those are just 2 quick ideas, more can be probably done.

Sounds much like a marketing activity - Not a security research.

I have to tell you. I analyzed the issue very carefully and on most aspects. All this things about the voice encryption analisys sounds to me like a marketing campaign of SecurStar GmbH to sell PhoneCrypt and gain reputation. A well articulated and well prepared campaign to attract the media saying, in an indirect way cheating the media, that PhoneCrypt is the only one secure. You see the press releases of SecurStar and of the “Security researcher Notrax telling that PhoneCrypt is the only secure product” . SecurStar PhoneCrypt is the only product the anonymous hacker “Notrax” consider secure of the “software solutions”.
The only “software version” in competition with:

- SnapCell - No one can buy it. A security company that does not even had anymore a webpage. The company does not almost exist anymore.
- rohde-schawarz - A company that have in his list price and old outdated hardware secure phone . No one would buy it, it’s not good for genera use.

Does it sounds strange that only those other products are considered secure along with PhoneCrypt .

Also… let’s check the kind of multimedia content in the different reviews available of Gold-Lock, Cellcrypt and Phonecrypt in order to understand how much the marketing guys pressed to make the PhoneCrypt review the most attractive:

Application Screenshots of application Video with demonstration of interception Network demonstration
PhoneCrypt 5 0 1
CellCrypt 0 2 0
GoldLock 1 2 0

It’s clear that PhoneCrypt is reviewed showing more features explicitly shown and major security features product description than the other.

Too much difference between them, should we suspect it’s a marketing tips?

But again other strange things analyzing the way it was done…
If it was “an impartial and neutral review” we should see good and bad things on all the products right?

Ok, see the table below regarding the opinion indicated in each paragraph of the different reviews available of Gold-Lock, CellCrypt and Phonecrypt (are the only available) to see if are positive or negative.

Application Number of paragraphs Positive paragraphs Negative paragraphs Neutral paragraphs
PhoneCrypt 9 9 0 0
CellCrypt 12 0 10 2
GoldLock 9 0 8 1

Detailed paragraphs opinion analysis of Phonecrypt
Paragraph of review Opinion expressed
From their website Positive Marketing feedback
Apple iPhone Positive Marketing feedback
Disk Encryption or voice Encryption Positive Marketing feedback
PBX Compatibility? Really Positive Marketing feedback
Cracking <10. Not. Positive Marketing feedback
Good thinking! Positive Marketing feedback
A little network action Positive Marketing feedback
UI Positive Marketing feedback
Good Taste Positive Marketing feedback
Detailed paragraphs opinion analysis of Gold-Lock 3G
Paragraph of review Opinion expressed
From their website Negative Marketing feedback
Licensed by The israeli Ministry of Denfese Negative Marketing feedback
Real Company or Part Time hobby Negative Marketing feedback
16.000 bit authentication Negative Marketing feedback
DH 256 Negative Marketing feedback
Downad & Installation! Neutral Marketing feedback
Cracking it <10 Negative Marketing feedback
Marketing BS101 Negative Marketing feedback
Cool video stuff Negative Marketing feedback
Detailed paragraphs opinion analysis of CellCrypt
Paragraph of review Opinion expressed
From their website Neutral Marketing feedback
A little background about cellcrypt Negative Marketing feedback
Master of Marketing Negative Marketing feedback
Secure Voice calling Negative Marketing feedback
Who’s buying their wares Negative Marketing feedback
Downad & Installation! Neutral Marketing feedback
My Demo environment Negative Marketing feedback
Did they forget some code Negative Marketing feedback
Cracking it <5 Negative Marketing feedback
Room Monitoring w/ FlexiSpy Negative Marketing feedback
Cellcrypt unique features.. Negative Marketing feedback
Plain old interception Negative Marketing feedback
The Haters out there Negative Marketing feedback

Now it’s clear that from their point of view on PhoneCrypt there is no single bad point while the other are always described in a negative way.
No single good point. Strange?
All those considerations along with the next ones really let me think that’s very probably a marketing review and not an independent review.

Other similar marketing attempt from SecurStar

SecurStar GmbH is known to have used in past marketing activity leveraging this kind of “technical speculations”, abusing of partial information and fake unconfirmed hacking stuff to make marketing/media coverage.
Imho a rare mix of unfairness in leveraging the difficult for people to really understand the complexity of security and cryptography.

They already used in past Marketing activities like the one about creating a trojan for Windows Mobile and saying that their software is secure from the trojan that they wrote.
Read about their marketing tricks of 2007

They developed a Trojan (RexSpy) for Windows Mobile, made a demonstration capability of the trojan and later on told that they included “Anti-Trojan” capability to their PhoneCrypt software.They never released informations on that trojan, not even proved that it exists.

The researcher Collin Mulliner told at that time that it sounds like a marketing tips (also because he was not able to get from SecurStar CEO Hafner any information about that trojan):

“This makes you wonder if this is just a marketing thing.”

Now, let’s try to make some logical reassignment.
It’s part of the way they do marketing, an very unfriendly and unpolite approach with customers, journalist and users trying to provide wrong security concepts for a market advantage. Being sure that who read don’t have all the skills to do in depth security evaluation and find the truth behind their marketing trips.

Who is the hacker notrax?

It sounds like a camouflage of a fake identity required to have an “independent hacker” that make an “independent review” that is more strong on reputation building.
Read about his bio:

¾ Human, ¼ Android (Well that would be cool at least.) I am just an enthusiast of pretty much anything that talks binary and if it has a RS232 port even better. During the day I masquerade as an engineer working on some pretty cool projects at times, but mostly I do the fun stuff at night. I have been thinking of starting an official blog for about 4.5 years to share some of the things I come across, can’t figure out, or just cross my mind. Due to my day job and my nighttime meddling, I will update this when I can. I hope some find it useful, if you don’t, well you don’t.

There are no information about this guy on google.
Almost any hacker that get public have articles online, post in mailing archive and/or forum or some result of their activity.
For notrax, nothing is available.

Additionally let’s look at the domain…
The domain infosecurityguard.com is privacy protected by domainsbyproxy to prevent understanding who is the owner.
The domain has been created 2 months ago on 01-Dec-09 on godaddy.com registrar.

What’s also very interesting to notice that this “unknown hacker with no trace on google about him that appeared on December 2009 on the net” is referred on SecurStar GmbH Press Release as a “An IT security expert”.

Maybe they “know personally” who’s this anonymous notrax? :)

Am i following my own conspiracy thinking or maybe there’s some reasonable doubt that everything was arrange in that funny way just for a marketing activity?

Social consideration

If you are a security company you job have also a social aspects, you should also work to make the world a better place (sure to make business but “not being evil”). You cannot cheat the skills of the end users in evaluating security making fake misleading information.

You should do awareness on end users, to make them more conscious of security issues, giving them the tools to understand and decide themselves.

Hope you had fun reading this article and you made your own consideration about this.

Fabio Pietrosanti (naif)

p.s. Those are my personal professional opinion, let’s speak about technology and security, not marketing.
p.p.s. i am not that smart in web writing, so sorry for how the text is formatted and how the flow of the article is unstructured!

Voice Security and Privacy slides

Below my slides on voice security and privacy from Security Summit 2009.

mmm, yes i am working in this area from 2005, will write again about it.