Schneier on Security

D B Carroll • December 5, 2011 1:02 PM

With regards to monitoring all keypress events, it may be that, on phone OS’s, it is the only way for the client to monitor any keypress events — like SetWindowsHookEx in Windows. What we need to know is, what gets logged and uploaded, what gets logged and kept locally for some period of time for batch processing later (and thus might be found and read by a third party), and what gets ignored immediately. In the Register interview it sounds like most keypresses are skipped immediately, but it’s hard to be certain, since the Carrier IQ guy doesn’t clearly distinguish between filtering on the client and filtering later, on some server.

One thing that the Reg’s interview did not follow up on is the following:

In other words, a phone with Carrier IQ on it may receive an SMS that has formatting in it that calls some sort of an API?

Right.

This sounds like a major potential security hole. If the formatting of Carrier IQ’s control messages becomes known, as now seems likely, then unless they have some sort of strong authentication mechanism for their control messages this could easily be a way for an attacker to siece control of the phone via a text message. Any bets on the strength of their authentication?

Another area of concern from the intervew that needs follow-up. Carrier IQ says:

Does that mean SMS messages are never logged?

The content of SMS messages are never logged. There are two things that happen when SMS messages are received. One is, obviously, we count them, the ones that succeed, the ones that fail. We do also record the telephone numbers the SMSs are from and to.

…

The content of the SMS is never stored and never transmitted.

…

How much data on the average phone running Carrier IQ is actually transmitted in a day, a week or a month?

This is a really important point because obviously the more that you take off a device the more processing power you’d need. If we were doing everything that was claimed, we’d be outstripping Google for requirements of architecture.

The typical upload in for customer care information is about 200KB. That’s about 200 times 1024 characters.

…

What percentage of that 200KB do you reckon is radio conditions? Would it be 80 percent, 20 percent?

It varies depending on the customer. It could be as much as 80 percent. Our advice to customers is to keep it within that 200KB framework.

How is this data transmitted? If it is ever transmitted over wifi, is it encrypted or not? If not, does it include positional data and incoming/outgoing phone numbers? If so, this would be extremely private data that is transmitted over the public internet.

As to the precise data collected, I reckon Carrier IQ can’t say because of NDAs with the carriers who install their stuff. So we would need to get a statement from each carrier as to exactly how they configure carrier IQ and what it transmits to them. For instance, are complete URL’s ever uploaded? It sure sounds like they could be — and I see no legitimate reason for the Carrier IQ client to need to monitor entire URLs (as opposed to, say, server connections at the time a call is dropped).

@ wiredog – one reason to install monitoring software on the phone is to record what you do over wifi connections. The phone company can’t see that — and I see no reason why they should need to see it in order to monitor the quality of their own network.

D B Carroll • December 5, 2011 4:41 PM

I’m a Windows developer not a phone developer, so I’m not sure I fully understand Trevor’s video. Is he showing:

1. Messages being passed to processes, like Spy++ on Windows?
2. Content output to the filesystem, like Process Monitor on Windows?
3. Content uploaded via some network connection?
4. Something else I don’t understand.

I am almost certain it is not #3.

Thanks!