More details are emerging that reveal the Carrier IQ smartphone application does exactly what the vendor says it does. These new findings directly contradict the nearly universal allegations of keylogging, spying, and tracking, all based on the uncritical acceptance of the original analysis by Trevor Eckhart.
Eckhart published his work several weeks ago in his blog and a 17-minute YouTube video, which to date has had more than 1.7 million views. His conclusions, which purport to show that the Carrier IQ code is a rootkit and keylogger, triggered a firestorm of invective, outrage, class actions suits and calls by U.S. senators and congressmen for investigations.
The new technical details about Carrier IQ emerge from one of the few attempts, if not the only one, to dissect the vendor’s code and see how it works: reverse engineering by security consultant Dan Rosenberg, who this week published the details of his analysis. Another source is Rebecca Bace, a long-time security researcher, and CEO of Infidel, a security consulting firm, who met with Carrier IQ designers and developers for several days last week to review the system and, specifically, to drill into the areas of the code related to Eckhart’s accusations. Bace’s background includes information security and systems monitoring, especially in monitoring functions tied to intrusion- and anomaly-detection systems.
Both say they do not have and have not had any kind of financial relationship with the Mountain View, Calif., software vendor.
The Carrier IQ software “cannot” record SMS text messages, Web page contents or email contents; and it “cannot” record text keystrokes (though it does record which buttons are pressed in the dialer app when making a phone call), according to Rosenberg, in his blog.
“I am using the word ‘cannot’ literally, as in ‘is not capable of, in the present tense, without being altered by modifying its code and installing a new version on the phone,'” Rosenberg writes. “It seems obvious to me that CarrierIQ could be modified in the future to perform nefarious actions: so could any application on your phone.”
Embedded by the phone maker with the operating system, at the behest of the carrier, the Carrier IQ program can receive from the OS specific measurements and changes in state on the device, and in some cases location data. Running a carrier-specific “profile” that identifies the subset of metrics the carrier wants, Carrier IQ then sends those metrics, as encoded data over SSL, to the server for analysis.
As such, Carrier IQ is not an after-market application but a “systems internal,” according to Bace, meaning it is part of the hardware-firmware-OS configuration specified by a cell carrier when it agrees to accept a specific phone on its network. “This is not unusual in complex system environments,” she says in an email. “They’re analogous to firms who develop and brand specific mechanisms for operating systems, such as…log mechanisms, debuggers, drivers for specific hardware components, etc. and whose products are fielded as integral parts of those systems.
“I’m accustomed to being a professional skeptic, but so far everything I’ve seen is consistent with the assertions made by the [CIQ] engineering and development team — they provide only that status information pursuant to diagnosing issues with the cellphone, and furthermore take pains to limit access to that information to the carriers controlling the solution,” Bace says.
Rosenberg is vulnerability research practice lead for Virtual Security Research, a Boston consultancy. He is one of a number of skeptics who last week began voicing reservations about the original analysis by Eckhart, a systems administrator in Torrington, Conn.
The analysis included the YouTube video posted by Eckhart that has been viewed repeatedly, and usually unquestioningly cited as “proof” that Carrier IQ is a “rootkit” that among other things enables the software vendor, the handset maker, and the carriers to read and record SMS messages, Web page content, passwords, and a potentially unlimited amount of sensitive, personal, or private user information.
Astonishingly, despite all the fulminations and outrage at online hacker forums, developer websites, and tech news sites, Rosenberg seems to be the only person who has attempted to disassemble the CIQ code and actually document how it works.
The analysis also sheds light on the behind-the-scenes interrelationships between software vendors, handset makers, and carriers when it comes to securing and managing smartphones.
The Carrier IQ smartphone application is designed to accept specific bits of information, dubbed metrics, from the OS. Also loaded on the phone is a carrier-determined “profile,” written by Carrier IQ: the profile identifies for the application what subset of those metrics the carrier is interested in. An event or change of state triggers a metric sent to Carrier IQ from the operating system. “On receiving a submitted metric, CIQ evaluates whether that metric is ‘interesting’ based on the current profile installed on the device,” Rosenberg writes. “Profiles dictate whether or not a piece of information is relevant for assessing a particular aspect of phone service, such as reception or battery usage.
“Note that the CarrierIQ application simply receives these metrics, collects them, and eventually uploads them to be analyzed by carriers [using the CIQ server application],” Roseberg notes. “All of the code responsible for determining which metrics are submitted to CIQ for processing is integrated into the phone’s application stack by the handset manufacturers themselves.”
Bace says, “The engineers at CIQ are extremely well versed in the internals of cellphones; they are similarly well versed in how cellular networks are managed. They started with some innovative ideas of how to manage the integration of both ends of the system more intelligently and have won market share because they delivered on those ideas. I can attest to the fact that none of those ideas have anything to do with monitoring users….”
That original focus on traditional Quality of Service measures has been extended with new functions focused on how users interact with their cellphones, or Quality of Experience measures, as part of how cell carriers judge the success of their offerings, Bace says.
This is born out by the 12 CIQ metrics Rosenberg found on the Samsung Epic 4G Touch smartphone, running Android. “In this analysis, I enumerated every CarrierIQ-related hook integrated into the Android framework and examined what metrics can possibly be collected, and just as importantly, in what situations,” Roseberg writes. “This list does not include metrics that may be submitted by the baseband, which include additional radio and telephony information.”
In his blogpost, a table lists the metric ID, the metric itself, the data sent, and the “situation” that triggers the metric:
* browser page render event
* location event, which can use GPS or other location data
* HTTP request sent, or response received (the URL, request type, content length, and so on but not page contents)
* network state changes, sending an “internal identifier”
* a range of telephony and radio events (such as a dropped call, service issues, and so on)
* hardware event, sending data such as voltage, temperature, battery level
* key presses, but only in the phone dialer application
* miscellaneous GUI state changes, such as battery state
* starting or receiving a call or a failed call, which sends CallerID, state, and phone number
* application events such as a stopped app, or a new app, sending the application name
* questionnaire event, used when Carrier IQ is configured to present the user with a service questionnaire
* SMS message received or sent, which includes message length, phone, number, status, but no text from the body of the message.
According to Bace, this data is kept only temporarily and is protected by a number of mechanisms. The data from these metrics is stored by CIQ in small, circular memory queues that are repeatedly and frequently overwritten. “This is by design to allow the diagnostic routine in question to retain state, which is necessary for them to diagnose any but the most trivial of problems,” she says. “I’ve seen lots of these as a common feature of security monitoring tools, with which I’ve worked for decades….The length of time buffers are retained can vary, as specific events may occur rarely, but they’re cleared when uploaded by carriers or else periodically as part of system housekeeping.”
Much of CIQ’s real-time processing is about converting raw data collected from user-controllable interfaces, and stored in the queues, into anonymized status fields, such as battery levels of a phone over reporting intervals or the number of bad connections with the cell system in given time frame. These fields are converted into status flags and uploaded on demand, or when status fields are full, or on a schedule specified by the carrier. “[N]othing bound to [the] user is written to storage,” Bace says.
Rosenberg’s categorical insistence that Carrier IQ “cannot” read SMS text messages, among other things, directly contradicts what many bloggers, developers and others have said is shown in the Eckhart video.
For example, Russell Holly, at Geek.com, was contacted by Eckhart during the latter’s work on the CIQ application. After Eckhart posted his video, Holly wrote about it in a lengthy post on Nov. 29. He included a screen capture from the Eckhart video, which shows debugging output, apparently via the Android LogCat utility for “collecting and viewing system debug output.” (“LogCat just prints out whatever is in the debugging logs on the device, and these are part of the Android OS,” notes Rosenberg).
The photo shows, at the top, activity by the “ciqagent” involving a SMS text message. Roughly two-thirds of the way down, you can read the text of the message Eckhart sent himself: “Hello world!”
Holly comments: “When you receive a text, the video demonstrates that the CarrierIQ software is aware of the text message and its contents before the phone notifies you that you have a message. CarrierIQ and Sprint both were adamant that the body of an SMS was not recorded, and yet we can clearly see in the video that the text contents are read and transmitted via the CarrierIQ applications.”
Holly took the time and effort to contact Carrier IQ, requesting additional information to clarify this apparent contradiction. The company declined.
So is this photograph “proof” that Carrier IQ, and therefore the handset maker and the carrier, can read your SMS text message?
No, says Rosenberg.
“What you’re seeing in Trevor’s video is actually two distinct events,” he says. And these have not been clearly distinguished in much of the uncritically accepting commentary about the video.
What you first see, Rosenberg says, are a “few debug messages, related to CarrierIQ, [which are] being printed out when an SMS is received.”
“These messages do not contain any sensitive data, and simply indicate that CIQ is doing *something* with SMS data,” he says. “My research has shown that what CIQ records are things such as the status of the SMS message (success or failure), the source, and the length, but not the contents. My research also showed that CarrierIQ does not even support the capability to record SMS [text] bodies even if a carrier wanted to, since none of CIQ’s metrics have a field dedicated to SMS bodies.”
Yet Eckhart’s video of the output does indeed show the body of the text message. What gives?
This is the second, distinct event, which is caused not by the Carrier IQ software, but by an “unrelated screwup by HTC,” the phone’s manufacturer, according to Rosenberg.
“HTC put debugging statements in their code, a common practice to help developers figure out what’s going on while they’re working on the phone,” Roseberg says. “These [HTC] debugging statements included code that outputs the bodies of incoming SMS messages. These printouts should have been disabled before shipping the phone, but for some reason that didn’t happen.”
“So seeing SMS [text] bodies in the [Eckhart] video actually has nothing to do with CIQ, and is an artifact of HTC failing to disable printouts that were intended for developers only,” Rosenberg says.
“As others have pointed out, the phone [Eckhart] used in the ‘expose’ was operating in debug mode, not standard operating mode for the models shipped to users by carriers,” Bace says. “He equated the appearance of data in his logs with export of that data to the network or, for that matter, with access to that data by others, even as he disabled the connectivity of the phone to the network. He presumed to understand the functionality of the CarrierIQ artifacts in the log without bothering to substantiate what they were doing with respect to writes-to-storage-devices, to system calls, etc.”
“I’m distressed that amidst the furor, there’s no acknowledgment that Eckhart isn’t a cellular network expert,” Bace continues. “To understand an endpoint device, especially one that is by definition under some central management control as a condition of connectivity, is only a part of understanding whether a threat or exposure exists.”
HTC’s failure to disable the display of the debug statements constitutes a legitimate potential security threat to user information. These are a “risk to privacy,” Rosenberg says, and HTC should mitigate that risk by disabling these debugging messages. But it’s not a risk created by the CIQ software or the data it is able to collect.
In his blogpost, Rosenberg spells out what the deconstruction of the CIQ code reveals about how the application actually works, as revealed by the metrics enabled for his Samsung phone. It matches Bace’s conclusions.
“Taking this information into account, all of the data that is potentially being collected supports Carrier IQ’s claims that its data is used for diagnosing and fixing network, application, and hardware failures,” Rosenberg concludes. “Every metric in the above table has potential benefits for improving the user experience on a cell phone network. If carriers want to improve coverage, they need to know when and where calls are dropped. If handset manufacturers want to improve battery life on phones, knowledge of which applications consume the most battery life is essential.”
“CarrierIQ exists for a legitimate purpose – to help carriers and OEMs isolate and diagnose specific classes of problems that affect mobile service,” Bace says. “The developers have taken great pains to minimize the impact their diagnostic functions have on the constrained resources present on the mobile devices. Furthermore, they have also taken great pains to put control of their software in the hands of their carrier customers, who have strong privacy policies and regulatory measures in place. They [CIQ] don’t access end user information; neither do they store such data. I’m mystified as to why anyone believes they should merit such abuse.”
Nonetheless, Rosenberg is critical of the way the Carrier IQ application has been implemented in the carrier-manufacturer relationship. End-users should be able to opt out of any sort of data collection; carriers should be clearer and plainer about what data is being collected from the phone, and why; and “there needs to be third-party oversight on what data is collected to prevent abuse.”
Finally, he says, the “legality of gathering full URLs with query parameters and other data of this nature should be examined.”
Rosenberg says he has shared with Eckhart about his own findings, based on running the Carrier IQ application through a disassembler. But so far, Eckhart has not posted anything new on his blog.
And that points to another set of criticisms that can be levied.
“To fail to differentiate an after-market app from a system internal that is integral to the management of the network to which the device is connected is a major failing,” Bace says of Eckhart’s original analysis. “To propose, as he has in the meantime, that he can provide a means of removing the offending mechanism – without disrupting quality of service -to a general populace of non-technical users is simply beyond the pale.”
