RIM BlackBerry smartphones have been deemed the most secure smartphones on the market for a long, long time. They indeed are quite secure devices, especially when it comes to extracting information from the device you have physical access to (i.e. mobile phone forensics). It is unfortunate, however, that a great deal of that acclaimed security is achieved by “security through obscurity”, i.e. by not disclosing in-depth technical information on security mechanisms and/or their implementation. The idea is to make it more difficult for third parties to analyze. Some of us here at Elcomsoft are BlackBerry owners ourselves, and we are not quite comfortable with unsubstantiated statements about our devices’ security and blurry “technical” documentation provided by RIM. So we dig.

Our first two targets are the apps providing secure storage of sensitive data: BlackBerry Password Keeper and BlackBerry Wallet. These applications are provided by RIM for free; Password Keeper is even included with each installation of BlackBerry OS. The two apps are the recommended way to store login credentials and other sensitive data such as credit card numbers. The data stored in those two apps could also be a wealth of information for investigators. According to RIM, all data is securely encrypted with AES-256. The encryption key is derived from user-specified master password, which can be different from device password. Password Keeper and Wallet master passwords can also be different.

Another notable fact is that Password Keeper and Wallet databases are included in the backup produced by BlackBerry Desktop Software. This means that, as a mobile forensics investigator, you can access those databases (containing encrypted data at this point) by either connecting suspects’ handset and running Desktop Software (if there is no password protection on the device) or by looking for stored device backups on suspects’ computer(s). And even if the backup you’ve been able to get a hold of is encrypted, our Elcomsoft Phone Password Breaker can recover the password for it .

Once you’ve got the (unencrypted) backup, Password Keeper and Wallet databases are accessible. The problem is that their data are still encrypted. And this is exactly what today’s EPPB release is about: recovering master passwords for Password Keeper and Wallet databases. Now you can load a BlackBerry device backup into EPPB and run password recovery against Password Keeper and Wallet databases. And what’s really good about this is that password recovery rate is great – hundreds of thousands and up to several millions passwords per second on modern CPU, depending on BlackBerry OS version. To the best of our knowledge, there were no tools capable of doing this until now, so we're proud to be the world’s first again, offering our customers unique functionality that’s not available in other vendors’ products.

So, you were able to discover the master password, what's next? Right now you have two options:

• Use BlackBerry Simulator, restore the backup to it, and use the recovered master password(s) to enter Password Keeper and/or Wallet. Access stored data as usual.
• Use Elcomsoft BlackBerry Backup Explorer, which can now show Password Keeper and Wallet data (as of version 9.61 being released today).

The third option to view Password Keeper and Wallet data within EPPB itself will be probably added with the next update. Speaking of updates, I'd like to tell you that this BlackBerry-related addition is really small compared to what's in the queue. If things go well, we hope to release "the next big thing" within 1-1.5 months from now. You're going to love it, I promise .

P.S. For those technically inclined out there, here’s a brief summary:

BlackBerry Password Keeper database format and protection is the same for OS 5, OS 6, and OS7. Per-item encryption key is derived by computing 3 (three) iterations of PBKDF2-SHA1 with master password and per-item salt.

Wallet database format and protection differs between OS 5 and OS 6/7.

For Wallet in OS 5, per-item encryption key is derived by computing 3 (three) iterations of PBKDF2-SHA1 with SHA-256 hash of master password and per-item salt.

For Wallet in OS 6 and OS 7, per-item encryption key is derived by computing a random number of iterations (between 50 and 100) of PBKDF2-SHA1 with SHA-512 hash of master password and per-item salt.

Encryption in all above formats is AES-256 in ECB (!) mode, SHA-1 hash of the data is appended before encrypting; data is padded as per PKCS #5.

In my opinion, should RIM have opted to be more open about their security mechanisms, someone (maybe even someone from their own team) could possibly point out that the level of protection against password recovery attacks is not sufficient for 2011.

• The ability to decrypt contents of the device keychain
• The ability to perform logical acquisition of the device
• Logging of all operations performed within Toolkit
• Support for iPhone 3G
• Support for iOS 3.x on compatible devices
• Support for iOS 4.3.4 (iOS 4.2.9 for iPhone 4 CDMA)
• Let me give a short description of each of the new features.

Keychain Decryption

Logical Acquisition

Logging

iPhone 3G and iOS 3.x Support

Compatibility with iOS 4.3.4 and iOS 4.2.9

When it comes to obtaining the contents of iPhone’s file system, mobile forensic specialists usually mention the following three opportunities:

1. One can 'mount' the device, mapping it as a drive letter and copy data file after file. In this mode, I/O requests are served by the file system driver on the device that’s supposed to ‘know’ the encryption keys for all files. Essentially, this means that analyst receives file data that is already decrypted during the transfer. The ‘mounting’ in this case is achieved by using undocumented interfaces provided by Apple iTunes, which makes the researcher rely on something that’s a) undocumented, and b) involuntarily provided by the manufacturer. The amount of data available depends on whether the device is booted into a so-called "jailbroken" state or not. Devices that are not booted into a "jailbroken" state allow access to significantly less information. In "jailbroken" state, all information stored on the device may be available.

It is worth mentioning that booting a device into a "jailbroken" state does not necessarily require a permanent "jailbreak" modification of the device, and can be performed without modifying data stored on the device, i.e. without violating read-only principle so important in computer forensics.

While relatively simple, the file-based approach has numerous limitations that make it less than ideal for forensic purposes. Since the transfer is done file-by file, the case quickly becomes difficult to manage. Typical file system contains tens of thousands of files so it might be quite a challenge to even store them in forensically sound way (i.e. making sure that no files are added, deleted, or modified after acquisition is complete). Another problem is that some files may be locked by running processes, may require additional privileges, symbolic links may interfere with the host system, etc.

2. The second option would be to decrypt file system as a part of acquisition process so that its result is a decrypted file system.

3. Finally, one can do a physical acquisition of the encrypted file system and decrypt the data off-line. This would require an additional step of extracting required keys off the device.

The last two options are indeed very similar. In both cases, I/O requests are served by storage driver (as opposed to file system driver in the first case), effectively bypassing proprietary file system drivers and avoiding all types of file locks and access permission problems. Both methods require the device to be in "jailbroken" state.

Although those last two acquisition approaches are similar and first one might seem more attractive on the first sight, we decided to go with the last one. In our eyes, there are numerous important benefits to doing the physical acquisition in a ‘raw’ way.

1. We believe that physical acquisition should be as close to the original device data as possible. The first method (mounting the device) relies on the file system driver to deliver decrypted file data. If we wanted to implement similar on-the-fly decryption during the physical acquisition process, the resulting image won’t be a bit-to-bit physical copy at all. Instead, we can do those actions off-line, and produce a decrypted image out of a precise bit copy.

2. Some device secrets such as the passcode or escrow keys might not be known at acquisition time. Without knowing those secrets, some files can not be decrypted. Off-line processing allows capturing and storing the original encrypted image while postponing the decryption to a later moment. An analyst can return to the original image if more secrets become available (e.g. escrow keys are discovered on suspects’ desktop computer) without having to re-acquire data from the physical device.

3. Analysts may have a backlog of cases. Re-doing the acquisition with a new tool might not be what they’re looking for. With off-line approach, one can obtain the keys from the device, which takes much less time than re-imaging it.

4. Forensics often already have a favorite (or the only approved) tool to do device imaging. For those who don’t, ElcomSoft can provide a basic one that just works. As long as the tool is capable of producing raw (dd-style) images, the analysts can continue using it.

5. Finally, the tools are not bug-free. The acquisition must be as simple and as straightforward as possible. Having to re-acquire the contents of a 64 Gb iPad because of a glitch in the imaging tool could be extremely frustrating and time-consuming. By performing the decryption as a separate process, one can reduce the risk of this happening.

The Toolkit

Elcomsoft Phone Password Breaker is available to general public. We will also provide eligible parties with additional acquisition Toolkit to use on devices running iOS 4.x. We’ll also provide detailed instructions. The Toolkit will allow the following:

• Extract hardware-dependent keys, file system keys and escrow keys from the device;
• Recover the passcode (subject to passcode length and complexity);
• Obtain bit-to-bit copy of device storage.

After obtaining an image of the device storage area accompanied by device-specific keys, analysts will be able to run Elcomsoft Phone Password Breaker to decrypt the acquired image and then analyze the decrypted image with the forensic tool of their choice.

Password recovery is one of most CPU-intensive tasks, and it fits best into multi-processor architecture. Every CPU (or CPU core) get its own portion of passwords to try (i.e. to check their validness), and they all work in parallel. As simple as that.

So what we’re doing in our software is running multiple threads – as many as the number of CPUs (or cores) available. And the rest is being done by the operating system, that assigns the threads to cores (well, in most cases we don’t care what particular core is going to execute a particular thread, because they are all equal; the only exception is when one or more of the cores is doing something already, I mean something CPU-intensive as well).

There is also such technology as Hyper-threading. With it, CPU exposes two virtual cores for each physical one it has, allowing operating system to run more threads simultaneously thus better utilizing CPU resources.

Now how it looks in practice. We have built the system based on one of the top Intel desktop CPUs – Intel Core i7-970. It has as many as 6 (yes, six!) cores running at 3.2 GHz, plus hyper-threading, so the number of virtual processors is twelve. This CPU is produced using (relatively new) 32 nm process, so power consumption is surprisingly not very high (130 W), but well designed cooling is still strictly recommended (even if you’re not playing the overclocker’s game).

Obviously, there is no reason to run more than 12 compute-intensive threads on this CPU, while the minimum number of threads is just one (you bet! ); we have not tried ALL variations from 1 to 12, but just some. What we were doing on this number-crunching twelve-heads monster is cracking the Blackberry backup file (using Elcomsoft Phone Password Breaker, of course). Here are the results:

The numbers are thousands passwords per second – so yes, the maximum performance we have got is well over 7 million (passwords per second). That means if the password is 7 chars long and contains small and capital letters, it will be cracked in a day and a half. Or if small (or capital) letters plus digits – less than 3 hours. And as you can see, the speed increases absolutely linearly up to 6 threads (according to the number of physical, not virtual cores). But when we double the number of threads (up to 12), the speed increases from 6,44 million passwords per second to 7,44 million per second only. So just 15% performance increase – but I wanted to remind you that the number of ALUs (arithmetic logic units) is still six. So hyper-threading does not double the speed, but still helps.

But 12 (virtual) cores is not the only strong side of this CPU. Also, it has the Westmere microarchitecture. That means (above many other things) that it features the new instruction set called Intel Advanced Encryption Standard Instruction Set (AES-NI), which is intended for hardware acceleration of AES. And as far as password verification for Blackberry backups uses AES, we do have hardware acceleration in EPPB with AES-NI (when it is supported by the hardware) as well. The results are (for one and twelve threads):

The first bar shows the speed with “old style” code (SSE2, in fact), and the second one with AES-NI. So the speed improvement is about 1.5 times – may be it sounds not so impressive as GPU acceleration, but it is just a free “bonus”! If, of course, you have an appropriate processor, in particular one of these:

• Gulftown (Core i7-9xx, Xeon 36xx, Xeon 56xx)
• Clarkdale (except Core i3, so just Core i5-6xx, and some Xeons)
• Arrandale (except Core i3 and Core i5-4xxM)

So, to make it simpler: most Core i5 processors have AES-NI supported, as well as six-core Intel Core i7 (9xx). If you have one of those, you can now break Blackberry backups about 1.5 times faster than you thought .

There is one [minor] problem, though. If the time needed to verify the password is comparable to the time needed to generate the [next] password, the performance start to drop. With the brute-force attack, it starts with 8 million passwords per second; with the dictionary attack much earlier – even with 12 threads, the resulting speed is about 2 million passwords per second only. The reason is pretty simple: we are not able to generate passwords that fast, especially when we perform all those nice mutations of wordlists passwords (changing the letter case, adding or replacing symbols etc). CPU verifies the password faster than we provide it with the new one .

Now if your partner gets a compromising anonymous image where you are enjoying yourself with nice blond with blue eyes or charming young man, don’t panic and don’t get upset, you can easily prove it is just a fake (even if it’s not ).  Seriously, how can we trust photographic evidence in the era of Photoshop and other designer tools? The genuineness of a digital image can only be proven by special digital tools…like OSK-E3?

Unfortunately or maybe fortunately, it turned out that OSK-E3 (Canon Original Data Security Kit) cannot guarantee image authenticity, because now it can recognize even fake images as true and genuine. However, the problem is not in OSK-E3, it is in Canon Original Data Security system implemented in most modern Canon DSLR (Digital Single-Lens Reflex) cameras.

Now it’s possible (well, Dmitry did it recently and who knows if somebody could do it earlier ) to dump camera’s memory, extract secret keys from the camera, and calculate ODD (= Original Decision Data) which answer for any changes done to the image. And thus name the modified image as original one.

What Canon can do? It seems like Canon can nothing do with their models right now, because the fundamental problem lies not in the software. Changing the software could possibly solve the question, until someone again finds its vulnerability. But adding cryptoprocessors that won’t expose the secret key and thus will prevent from any penetrations from outside would close the loophole.

Have a look at some of our fake images that pass verification test by OSK-E3: http://www.elcomsoft.com/canon.html

So, can you now trust Canon’s OSK decision if an image is original or not?

This brand-new iPhone 4 is capable of doing 1.4 millions MD5 iterations per second, about 35% more than iPhone 3GS.

I haven’t found any information on iPhone 4CPU clock frequency, but if we assume that it uses same chip as iPad (which seems to be the case), then exhibited performance corresponds to roughly 775 MHz.

So I’ve quickly coded an app which computed performance in MD5 hash computations per second, and here are the results:

The performance scales almost linearly (with respect to CPU frequency) for iPhone 3GS and iPad.

For iPhone 3G this is, however, not the case. Although CPU clock is only 1.5 times slower when compared to iPhone 3GS, overall performance is three times slower.

Puzzled, I did some research and found out that iPhone 3G and iPhone 3GS are using very different CPU cores indeed (link). The key difference is that iPhone 3GS uses dual-issue superscalar CPU which allows executing two instruction per clock. iPhone 3G utilized single-issue scalar core, and is thus limited to executing single instruction per clock. This perfectly explains missing factor of two in performance vs. clock rate difference between iPhone 3G and 3GS.

Developing software for ATI cards is (okay — was) a nightmare. In 2009 ATI quietly introduced two changes in their drivers which made previously perfectly functional and compatible applications to crash (if you are curious: with Catalyst 9.2 or 9.3 they’ve changed names of supporting DLLs bundled with drivers; with Catalyst 9.9 or 9.10 they’ve probably changed format of underlying binary so that anything compiled and linked in with earlier versions caused a driver to crash).

Well, with the release of Catalyst 10.4 drivers ATI is again at it. This time problem only affects users who have display adapters from different vendors in their computer. Applications utilizing ATI Stream will work on such configurations just fine with Catalyst 10.3, but once you upgrade to 10.4, applications will crash with faulting module being aticaldd.dll, a part of ATI Display driver. Kinda embarrassing, I would say. Regression testing is really something one with millions of users should consider.

Users of our software relying on ATI hardware accelerations (as well as any other ATI Stream enabled applications) should not update to 10.4 if ATI Readeon is not the only card in their computer.

From developer's point of view NVIDIA has always been superior. Ease of use, quality of SDK and drivers, thorough documentation. Apparently, they have invested a lot in developing, promoting and supporting CUDA.

Developing software for ATI cards is (okay — was) a nightmare. In 2009 ATI quietly introduced two changes in their drivers which made previously perfectly functional and compatible applications to crash (if you are curious: with Catalyst 9.2 or 9.3 they've changed names of supporting DLLs bundled with drivers; with Catalyst 9.9 or 9.10 they've probably changed format of underlying binary so that anything compiled and linked in with earlier versions caused a driver to crash). And there was almost no documentation with 1.x ATI SDKs.

But when it comes to pure mathematical performance (that is, not counting memory transactions) ATI cards are faster than NVIDIA counterparts, usually by far. Sometimes by very far. That's why we've been supporting them for more than a year already.

Next week we're going to update two of our applications — Elcomsoft Wireless Security Auditor and Elcomsoft iPhone Password Breaker. Among other things, they will support the use of both NVIDIA and ATI cards at the same time. Although I don't think this is a very common scenario, we've had some questions regarding possibility of such configurations.

Well, the answer is — it works! To verify this we've put GeForce GTX 295 and Radeon HD5970 into the same PC and tried to make this configuration work. This is how it looks before connecting power cables:

And this is how it looks after:

With Windows 7, there were no problems installing drivers for both cards, everything went smooth. We have used Catalyst 10.2 and Forceware 196.75 (it has been removed from website due to problems with fan control; I believe 196.21 will also work just fine).

If you will try to do this yourself, beware of one catch. After you have installed drivers you will see both ATI and NVIDIA cards in Windows Device Manager, but EWSA or EPPB will show only cards from one vendor. To overcome this you'll need to connect monitors to both cards and extend your Windows Desktop onto both of them. If you'll do this, our programs will be able to recognize all cards and you end up with something like this:

In fact, you can use both cards even with Windows XP! This is, however, not so smooth as with Windows 7. Performance for ATI cards is worse in XP, too. The funny thing is that XP seems to be unable to boot with two display drivers installed, so you have to uninstall one driver first, reboot, and then install it again (do not reboot!). Connect second monitor, and our programs will recognize cards from both vendors. If you will try to reboot, you will end up with BSoD and will need to boot in Safe Mode, uninstall one of drivers, and start over. Here's screenshot of EWSA running under XP x64:

EDIT: Some discussion on performance and architecture of next-generation GPUs have been removed in accordance with NVIDIA request.