SmartPhones - Can you Trust your USB Charger?

SmartPhones - Can you Trust your USB Charger?

One of the biggest trends in the consumer electronics sector, over the past few years, has been the rise in the use of the now ubiquitous USB connection as the primary mechanism to charge a portable device.

By Context

Leading cyber security consultancy

28 Jan 2011

This makes perfect sense from the point of view of both the manufacturer (fewer parts) and the consumer (less hassle). This is no more prevalent than in the mobile phone industry, where even the European Commission has set out a memorandum of understanding [1] to make Micro USB the de-facto charging connector on mobile phones (quite how much this means in practice is another matter).

Now at this point it could be asked, what has this to do with security? Well one subject that isn’t broached that often is in almost all these devices the USB port is still the primary mechanism to synchronise data and configure the device. Sure many devices can be configured to synchronise over Bluetooth or Wi-Fi but rarely come out of the box in such a state, for a very good reason.

Now imagine this scenario (as hypothetical as it is):

“You are in an unfamiliar part of the country, your smartphone’s battery is running dangerously low but as it is your primary means of communicating and doing business you must find somewhere to charge it. You spy an Internet cafe, knowing your device can charge over USB you rush in, pick a seat, a coffee and plug it in. Breathing a sigh of relief, you relax with your latte till enough charge is available to go on your way.”

Of course what you didn’t realise is the computer was infected with malware, which just stole all the data on your phone and sent it back to its masters. With business phones this could be all your confidential emails, your important customer contacts, plans for future expansion, and, well the point has been made. A paranoid nightmare of the dangers of ubiquity? Almost certainly, but it is something which should be seriously considered by both device manufacturers and corporate security managers alike.

With this in mind let’s take a look at two different Smartphones to see how they handle this situation. The ones chosen are the RIM Blackberry and the Apple iPhone. These devices were chosen because they are ones that Context is most often asked to assess for secure deployment in the enterprise.

Both devices were tested with a basic corporate policy deployed, primarily to prevent access to the device through the enforcement of a complex password as well as being installed with the latest operating system available at the time. The test assessed what a “rogue” charging point would have to do to gain access to the device, and if in the worst case access was granted what information could be directly extracted. Also no consideration was made for issues outside of the basic design, e.g. while some phones have in the past (and for that matter the present) been exploitable via the USB connector to escalate privileges and access more data than was designed, this is inadvertent and generally ephemeral functionality. OS upgrading or restore processes were also not considered as they would generally require rebooting the device which is more likely to be noticeable. 

Blackberry (OS Version

The official utility to synchronise data between the device and a computer is the Blackberry Desktop Software, an open source implementation to do a similar job is available called Barry [2].

Depending on the device’s policy configuration this can synchronise media and perform backup and restore operations. Access to the device is integrated with the existing password protection mechanism (if configured), including recording the number of failed attempts and wiping the device if configured to do after a set number of failures. It should not be possible to access anything of consequence without knowing this password.

The password is not sent in plain-text to the device, the computer first receives a challenge value which is SHA1 hashed along with the SHA1 hash of the password. The final hash is sent back to the device which will determine whether access is granted. This challenge process does prevent the pairing process from being trivially replayed, although if the traffic were to be captured this simple hashing mechanism would not be especially resistant to a brute-force attack. Still, this is more than sufficient to prevent opportunistic access without knowledge of the password.

Once access is granted the attacker could proceed to perform a backup. The Blackberry exposes the contents of the device through a series of databases which can be enumerated and individually accessed via the connection. There are a number of IT policies which can restrict what data can be accessed in this manner. A secondary measure comes into play if device encryption is enabled in the IT policy; the phone’s interface must be unlocked by the user in order to access any of the databases. If it is currently locked then the password prompt will appear on the device’s screen. If access to the backup data is permitted the contents are all completely unencrypted. While the Desktop software provides the option to encrypt backups it is not enforced by the device and is done on the host computer.

There are a few other areas which are not subject to this secondary locking mechanism however, basic device information is extractable and interestingly you can take screenshots of the display. If the device is locked, taking a screenshot might not be particularly useful, unless some interesting information is present on the lock screen. However if the user were to access the device while it was connected to the PC it would be possible to gather useful information.

The device also exposes a USB Mass Storage interface, which can be disabled through policy. If a password is required to access the device the user will be prompted for the password before access to the mass storage is permitted. 

iPhone (IOS 4.2.1)

Apple’s device synchronisation revolves around their iTunes application, although a free implementation of the protocol is available [3]. If the device is configured with a password iTunes will not be able to initially pair to the device as long as the phone is currently in a locked state. Note that the device must be password locked, the standard screen lock is not sufficient.

Once the user has input the password on the device’s interface, it will be possible for the pairing to succeed. The iTunes application does this by generating a unique X509 device certificate, chained to a self signed root and sending the certificate and its root across. The device stores the root certificate information against a unique host identity and this is used to validate pairing in the future. 

The data in the certificate is largely irrelevant; the phone does not check the subject or the valid date range (as you might expect it to). For all its use of PKI it seems likely that this is only for the purposes of obfuscation, as effectively all this process does is generate a unique blob which can be replayed at a future date to gain automatic access to the device, even if subsequently the password becomes locked.

The normal experience when using iTunes is to see some activity during this process because it will automatically attempt to synchronise or backup device data, however the pairing itself can be done completely silently and without any further user interaction. There is no penalty from an attacker’s point of view if the attempt to pair fails.

As a brief aside, in the case of iTunes this pairing material is stored at the machine level (in the 'All Users' folder on Microsoft Windows, or in /var/db on OSX). This is an odd choice considering the phone is almost certainly not a shared device, yet the pairing information is stored so anyone who uses that same computer can access and extract the information. Also without greater access to the device’s file system (such as through a Jailbreak) there does not seem to be a mechanism to determine what devices have paired to your phone. You cannot delete a pairing without restoring the device to factory default settings, unless you know the pairing information.

Once a valid pairing has been achieved the phone can be backed up, which copies most of the contents of the device including messages (locally stored emails and SMS), phone logs, contacts etc. This backup can be configured to be encrypted by selecting the appropriate option in iTunes, it can also be enforced through a deployed policy. In this mode all backup data leaves the phone encrypted. The first time backup encryption is enabled the user will be asked for a password, unfortunately this password does not adhere to the device’s password policy (if one is deployed); it would be perfectly acceptable to set an extremely weak value.

This is unfortunate as it has been shown that the password is the only piece of information required to decrypt the backup, and if necessary it can be brute forced (admittedly slowly) [4]. If the backup is encrypted then the phone will also save more data, for example it backups a portable version of the device key ring (which could expose web site logins, Wi-Fi passwords, exchange accounts and more). It is also claimed to backup an escrow key file which would allow the “data protection” feature of iOS 4 to be circumvented [5]. Of course if backup encryption is not enabled then a malicious application could enable it temporarily with a known password, backup the phone contents and disable it again.

If backup encryption is enabled and the password is strong, then it is unlikely to be brute forced as there is still some information which could be extracted. Basic device information such as the phone number of the Subscriber Identity Module (SIM), the International Mobile Subscriber Identity (IMSI), and International Mobile Equipment Identity (IMEI) can be gathered. It is also possible to “synchronize” a few select items such as 'Contacts and Notes' even with the encryption enabled.

Of course the entire data gathering does display a ‘synchronizing’ screen on the device while in operation; however this isn’t significantly different from the normal charging screen to necessarily be noticed if done just as the device is connected.

File system access, e.g. for your MP3 collection or photos is via a custom protocol on top of the device synchronisation connection, there is also a Picture Transfer Protocol interface for photos as a separate USB camera device.


The following tables summarise what can and cannot be access in various states.

Table showing what can be accessed if no password enforced:

* Although can be encrypted
** Except with a debug disk image which is tired to a specific phone

Table showing what can be accessed if the password is enforced and the device locked without having any knowledge of the password: 

Table showing what can be accessed if the password is enforced and the device is unlocked without having any knowledge of the password:

* Although can be encrypted
** Except with a debug disk image which is tired to a specific phone

Table showing what can be accessed if the password is enforced, the device unlocked and knowledge of the password obtained:

* Although can be encrypted
** Except with a debug disk image which is tired to a specific phone

Table showing what can be accessed if the password is enforced and the device locked with knowledge of the password: 

* Although if device encryption enabled user is prompted for password on device

Table to show if the user can determine whether something is accessing data based on indications from the device (such as visual changes or sound effects):


So what can be concluded from these two, different approaches to the handling of the USB synchronisation protocol? Well the Blackberry seems to take the more secure approach, requiring the exact same password to be input no matter what mechanism you use to access the device. For the initial pairing it also does not consider the state of the phone. This should make it more difficult for malicious software to gain access to the device in the first place.

Of course if the password was weak it might be possible for a “rogue” charger to brute force it before the corporate policy wipes the device (which might in fact make it useful for malicious purposes). Once access is granted unless the policy locks down what can be backed up, or the device encryption is enabled there is no longer any protection.

The iPhone takes the opposite approach, trusting the user gave implied consent for a USB host to access the device by plugging it in while unlocked. How many people would remember to always lock their device before charging would be something which would have to be objectively tested, but it could be expected to be low. Unlike the Blackberry there is no penalty for failing to pair; an attacker can run a repeating pairing process until an unlocked device is connected. The unusual approach of once paired, always paired might make sense for your average consumer but makes less sense for an enterprise device. On the positive side, encryption of backups can be enforced, and presuming the user configures a strong password, although it cannot be controlled by policy for some reason, then only some basic information such as contacts and notes can be extracted, as well as anything stored in the media partition.

From an enterprise policy point of view this shows how critical it is to enforce a strong password policy on all managed devices, especially on the Blackberry. As it stands for the iPhone it would be highly recommended that managed devices are deployed with backup encryption enforced and the administrator pre-configures the backup password to ensure it is strong. Doing this would not prevent the user from backing up their device, the only thing it would prevent would be unassisted restoring (as iTunes asks for the password before allowing the user to restore the data).

So how could this situation be improved for the future? Certainly having the ability to enforce some sort of user confirmation before access is granted to a device (maybe configured through policy) would be a good idea, if only to prevent rogue pairing. More control over the iPhone via policy would also be beneficial, especially being able to enforce backup password complexity and possibly even disabling backup completely.

For details about security of Smartphones in the enterprise please see Context’s white paper on the subject, read the Context Smartphone White Paper.


[1] - Memorandum of understanding -
[2] - Barry -
[3] -
[4] -
[5] -

Subscribe for more Research like this

About Context

Leading cyber security consultancy

CHECK IT Health Check Service
Cyber Essentials
CESG Certified Service
First - Improving Security Together
BSI ISO 9001 FS 581360
BSI ISO 27001 IS 553326
PCI - Approved Scanning Vendor