SMobile Global Threat Center - Analysis and Comparison of iPhone 3G, 3GS and - Contact Crypt Encryption Technologies

8/14/2019 SMobile Global Threat Center - Analysis and Comparison of iPhone 3G, 3GS and - Contact Crypt Encryption Technologies

1/52

4320 E. 5th Avenue Columbus, OH 43219phone: 614-251-2238 fax:614-251-4083

www.smobilesystems.com

SMobile Global Threat CenterAnalysis and Comparison of iPhone 3G, 3GS and

ContactCrypt Encryption Technologies

Troy Vennon, CISSP, CEH, GTC Research EngineerMayank Aggarwal, GTC Research Engineer

Chunyu Jiang, PhD., Director of Research and DevelopmentShinta Salim, Software Engineer


2/52



Contents

Overview ..............................................................................................................................................3

Purpose ................................................................................................................................................3

Executive Summary ..............................................................................................................................4

Methodology .........................................................................................................................................4

Test Goals ............................................................................................................................................5

Baseline................................................................................................................................................6

Baseline Configurations ....................................................................................................................7

Test Cases .....................................................................................................................................25 Case 1: .......................................................................................................................................25 Case 2: .......................................................................................................................................29 Case 3: .......................................................................................................................................32 Deleted Contact: .........................................................................................................................35 Case 4: .......................................................................................................................................39 Case 5: .......................................................................................................................................43 Case 6: .......................................................................................................................................48

Synopsis.............................................................................................................................................52

Table of Results..................................................................................................................................52


3/52



Overview

Apple's iPhone 3G and 3G S offer the capability to protect the phone's data from unauthorized usersby setting a four character passcode in order to access the springboard and consequently the phone'sapplications. The iPhone 3G does not currently offer any other version of data encryption on thehandset. However, the newly released iPhone 3G S offers an attempt at hardware encryption on thedevice to encrypt its data in a couple of different scenarios and this document will outline the specificsof the 3G S hardware encryption, and its failures. When tethered to and managed by Apple's iTunesapplication, the user is also granted the ability to perform certain maintenance tasks, includingperforming backups of the device. Beginning with iTunes version 8.1 and with iPhone 3G, the user isgiven the ability to encrypt the phone's backup by supplying an additional passcode that can beapplied to iTunes prior to a backup being performed. This function essentially encrypts the files thatare created during the backup process so they can be stored in a secure manner.

Research has shown that there are tools and techniques available to bypass certain aspects of thesecurity controls applied to both the iPhone and iTunes. Given the proper tools, knowledge andaccess to the handset, an attacker can simply bypass the passcode protections that iPhone offers togain access to the phone's applications. Additionally, it has been proven that it is possible toeffectively bypass the encryption performed by iTunes when performing a backup. The combination ofbypassing the handset's passcode security, bypassing iTunes' backup encryption capabilities and theinherent flaws in the implementation of iPhone 3GS encryption allow an attacker to gain access tosensitive information residing on the handset.

PurposeSMobile Systems has developed an application called ContactCrypt that was designed to address thelack of user data encryption available on the iPhone 3G and to supplement the weak encryption madeavailable on the iPhone 3GS. ContactCrypt is designed to allow the user to encrypt and decrypt thecontents of sensitive information within the Contacts section of the iPhone. While the iPhone wasdesigned for the easy development of gaming and other entertainment applications, the lack ofmeaningful API ! s and prohibited access to core components of the operating system make thedevelopment of third-party security applications nearly impossible. Notwithstanding, SMobileengineers were able to develop ContactCrypt to fully function within the limitations of a non-Jail brokeniPhone device and the application is currently available on Apple ! s App Store. Given additional API ! sand operating system access, encrypting other components of the iPhone would take minimal effort bySMobile development engineers.

With the revelation that it is possible to bypass the security controls native to the iPhone 3G/3G S andiTunes, the SMobile Global Threat Center (GTC) set out to directly compare the forensic results ofencrypting contact information via the means made available by Apple to the encryption capabilities ofSMobile Contact Crypt.


4/52



About SMobile

SMobile Systems, founded in 2002 and headquartered in Columbus, Ohio, is the world leader inproviding comprehensive software security solutions for all major mobile device platforms, includingBlackBerry, Windows Mobile, Symbian, Palm, iPhone and Android.

In response to the growing demand for mobile device security, SMobile has created a complete mobilesecurity suite including AntiVirus, Firewall, AntiSpam, Anti-Theft and Identity Protection, Secure MobileBanking, and Parental and Enterprise Controls.

SMobile is noted as having the only Antivirus and AntiSpyware solution in the world to supportBlackBerry devices and in November 2008, was the first company to offer an Antivirus solution forGoogle Android.

Executive SummaryThrough the development of a baseline handset configuration, the GTC was able to perform a seriesof tasks that duplicated the process required to bypass the security controls in iPhone and iTunes. Aseries of tests were then performed that revealed the encryption status of the handset's data while thehandset was in various states of configuration.

Testing has shown that SMobile's ContactCrypt provides adequate protection to sensitive contact datawhen iPhone security and iTunes backup encryption features have failed. Additionally, ContactCryptaddresses an exposed weakness in the way that the iPhone contacts database handles deleted ormodified contacts that could expose the information to an attacker.

MethodologyResearch into iPhone's security features has revealed versions up to and including the iPhone 3G Srunning firmware 3.0 offer very little protection of user data and applications from an unauthorized userwho has gained physical access to a device. Several methods for bypassing the security controls ofthe passcode and iTunes backup encryption have been identified and are well documented on theInternet. Of these methods, the forensically sound method of bypassing the device's passcode,developed by Jonathan Zdziarski, offers a method for bypassing the device's passcode whilepreserving the data on the handset.

The GTC thoroughly researched Zdziarski's tools and methodologies and determined that, while hismethod is preferable when data must be preserved, the use of the tools and scripts needed wouldn'tprovide any better access to the underlying operating system than a device that was jail broken with

the publicly available tools. Therefore, it was determined that performing testing on a jail brokendevice that subsequently had contact data inputted and encrypted would be sufficient to determine ifthe application was functioning correctly and could be done so without publicly disclosing thoseprogram and methodologies within this document.

For our testing, the GTC performed testing on the 3G and 3G S devices. The testing was performedside-by-side to ensure the ability to identify any differences in findings based upon different versions ofthe device. It is important to note that with the exception of the firmware build specific for the 3G and


5/52



3G S, as well as the tools we chose to jail break the devices, every other stepin the testing was performed in the same manner and there was no differencein the findings between the two devices.

For the purposes of illustrating the step-by-step processes required to gain access to the device forour testing, this document will focus its attention on building and jail breaking the 3G device. Wherethe process was different for the 3G S device, differences in tool use and the experience will be noted.

Test GoalsThe ultimate goal of the testing outlined in this document is to determine whether ContactCrypt wasproperly encrypting contact data on the device after iPhone's encryption capabilities had failed.Primarily, the testing team needed to ensure that the processes to bypass the device's passcode andto bypass iTunes backup encryption mechanism worked properly and would not adversely affect userdata.

The iPhone passcode is enabled or disabled according to the existence of a particular record in thekeychain database that manages all passwords for every application or function that requiresauthentication. Since OpenSSH will be installed and configured to allow the root user toauthenticate, this keychain can be accessed on the underlying operating system of the device bybrowsing to the /private/var/Keychain directory. Inside that directory exists the keychain-2.dbdatabase file that contains records correlating to each application's authentication credentials,including the record that dictates whether a passcode is set for the handset or not. Removing thisrecord effectively removes any passcode that was set on the device after a reboot.

Secondly, the testing team needed to be able to illustrate that the iTunes backup encryptionfunctionality could be bypassed as well. Looking into the keychain database reveals an additionalrecord that correlates to whether a backup password has been configured through iTunes to force allbackups to be encrypted. Removing this record effectively tricks the device into believing that nopassword has been configured through iTunes so the device does not need to process the data toiTunes is such a way that it will be encrypted. As an interesting aside, removing the backup passwordrecord from the database does not change the fact that the Encrypt iPhone backup selection iniTunes is still checked. If a normal user were unaware that the encryption mechanism in iTunes hadbeen bypassed at the handset level, they would have no way of knowing that the backup was notbeing encrypted by simply observing the settings through iTunes.

It is entirely possible to bypass the above mentioned security controls by simply removing or renamingthe keychain-2.db file and rebooting the device. However, removing the entire database also removesany authentication settings that may be required for other applications, such as email, IM, WiFi and,particularly important for this test, ContactCrypt. Through various tests, the GTC determined it best to

just remove the particular records that were needed to bypass the passcode and backup encryptionand leaving the extraneous records intact.


6/52



BaselineThe GTC defined a baseline configuration for the iPhone devices that would allow for the testing ofvarious levels of security and encryption, bypassed or not. It is important to establish that the processof jail breaking the device allowed for the installation of Cydia, OpenSSH, SBSettings andContactCrypt onto the device, as well as allowed root access to the underlying file system that isnecessary to move the device to different levels of security for testing purposes. For iPhoneconsumers, ContactCrypt can be easily installed via the Apple App Store.

The baseline configuration that was chosen is as follows: iPhone 3G and iPhone 3G S Firmware version 3.0 (7A341). A good repository for iPhone firmware can be found here .

! iPhone 3G Firmware: iPhone1,2_3.0_7A341_Restore.ipsw! iPhone 3G S Firmware: iPhone2,1_3.0_7A341_Restore.ipsw

iPhone 3G jail broken with RedSn0w iPhone 3G S jail broken with Purplera1n Cydia installed OpenSSH installed from Cydia No passcode set on device Contact exists as following:

! iPhone 3G:" Name: Jane Doe"

Phone#: (555) 123-0987" Organization: Testers Unlimited" Email: [email protected]" Homepage: spoon.com" Address: 90909 Broad St

Columbus, Oh 43222! iPhone 3G S:

" Name: John Smith

" Phone#: (808) 444-4444" Organization: Eight-0-Eight State Inc." Email: [email protected]" Homepage: myspace.com" Address: 15151 Main St

Reynoldsburg, Oh 43312


7/52


8/52



3. Once the device has powered off, it's time to begin the sequence that places the device intoDFU mode. With the device powered off, simply press and hold the power button and thehome button at the same time and count to 10 (100, 200, 300...), then let go of only the powerbutton, while continuing to hold down the home button for another 20 seconds.


9/52



4.

If you're using Windows, somewhere around 10-15 seconds of holding just the home buttonyou'll hear an audible beep that alerts you to the fact that the system has recognized that adevice is connected to the USB.


10/52



5. After that audible beep, open iTunes. When iTunes is open you'll seewindow pop-up saying that iTunes had detected an iPhone in recovery mode, click OK:

6. At this point, you'll be given the opportunity to restore the device. Notice the Restore button.If you simply click this button, iTunes will go out and check with Apple for the most currentfirmware version available for your device. At the time of writing this document, the mostcurrent version is 3.0.1. We are specifically interested in restoring the device to version 3.0. Inthe Baseline section of this document, we have provided a link to a site that maintains allversions of iPhone firmware versions. Navigate to that site and download the firmware versionof your choice (we chose 3.0.0 (3G): iPhone 3G Firmware:iPhone1,2_3.0_7A341_Restore.ipsw)


11/52



7. In order to be able to specify the firmware that you downloaded, inWindows, hold down the shift key and click on restore. In Mac, hold down the option buttonand click restore. You'll be given the option to browse for the firmware bundle:

8. Assuming you have selected a compatible firmware bundle, you'll see the following processes:

Extracting software:


12/52



Preparing Restore:

During the preparation step, you'll notice that the screen on the handset goes from blank todisplaying an apple and a progress bar

Restoring Software:

Restoring Firmware:


13/52



Verify Restore:

After the installation has completed, this is where there was a slight divergence between therestore of the 3G and the 3G S. The 3G S device continued on to reboot into a fresh install.However, the 3G device showed an error in iTunes indicating that the restore had failed:

10. Research indicated that the (1015) error did not indicate a failure in the restoration process.The error indicates that there was a compatibility issue with the baseband that was running onthe previous firmware than the one that was just installed. Research also indicated that theinstall completed successful, however the device will likely be placed into a recovery loop (notDFU) as iTunes believes there was a failure. A recovery loop means that when the devicereboots, it will only boot into recovery mode and iTunes will continually believe that the phoneneeds to be restored. If you are in recovery mode, you'll notice the device's display looks likethis and all manual attempts to leave recovery mode just bring you back to the same place:


14/52



11. In order to break out of the recovery loop, we need to interface withiBoot to tell the device what to do. In order to interface with iBoot/iBSS, we chose to useiRecovery. iRecovery is considered to operate universally in Windows and in Mac. We choseto use a Mac Mini to run iRecovery

12. To begin, we downloaded iRecovery and unpacked the two relevant files to the desktop.

13. We then copied libusb-0.1.4.dylib file to /usr/local/lib

14. We then opened a terminal and navigated to the Desktop and ran the following command:

iRecovery -s

15. You should see something like this, which indicates that iRecovery has been able to

communicate with iBoot:


15/52



5. If you receive an error that states the following:

got usb

no iphone/ipod found

simply unplug the USB cable, force the device to power down by holding down both the

power and home button at the same time for 10 seconds, then reconnect the USB cable.Once reconnected, run the command again.

6. After you have been able to get iRecovery to recognize the device, run the following commandat the command prompt:

fsboot

**A lot of available information on the Internet says that you need to modify the boot parameters using iRecovery. We simply ran fsboot and it worked.

7. It may be necessary to run this command several times before the device responds, as youmay be able to make out in the terminal screen of the screen capture shown below:


16/52



8. From here, you should see the device's screen display a picture of anapple with a status bar beneath it. Disconnect the USB cable and thedevice will reboot.

9. You'll notice that when the device reboots, it will only allow you to make emergency calls. Thisis because the device is not yet activated.

10. Simply connect the USB cable and open iTunes. The device will be activated and you canaccess the springboard. You'll also notice that you're required to setup some configurationsettings in iTunes that tells it how to handle syncing tasks. Go ahead and make those changesif you like, it's not necessary, since we're getting ready to jail break the device and install acustomized firmware that gives us access to the OS.

11. Jail breaking the devices was the second place where there is a slight divergence between the3G and the 3G S. We chose to use Redsn0w for the 3G device and used Purplera1n to jailbreak the 3G S device. We'll address the 3G, since there are screen captures to accompanythe procedures. For the 3G S and Purplera1n, we found that the process was much simpler asthe onscreen instructions for entering DFU mode were easier to understand. However, sincewe have screen captures for Redsn0w and it will work for 3G and the 3G S device, that's whatwe'll discuss. (Note: these instructions are for Windows users. Mac users should seesomething very similar.)

12. Download and unpack Redsn0w from the Dev-Team.

13. Navigate to the folder where Redsn0w was unpacked and run the executable.


17/52



14. When Redsn0w starts, you'll be asked to provide the correspondingIPSW file for your CURRENT firmware. This should be the same firmware bundle that wasused to restore the device in the previous portions of this document. Click "Browse:

15. Navigate to the correct IPSW file and open it:


18/52



16. Once the IPSW has been successfully identified, click "Next":

17. You'll see a progress bar flash across the screen that says it is patching the firmware. At thispoint, you'll be given the opportunity to tell Redsn0w how you want to customize the firmwareto jail break the device. When asked, ensure that "Cydia" is checked and click "Next".


19/52



18. The next step in the process is to put the phone into DFU mode. Theinstructions that will be provided can be interpreted to be rather confusing. This step simplyrequires that the device is powered off and the USB cable is connected to the device. In ourexperience it doesn't matter if iTunes is running in the background or not. Once you have

powered off the device and are ready to proceed click Next.


20/52



19. When you click Next, just remember the process for entering DFU mode. Don't pay as muchattention to what the instructions are saying, just remember to count (100, 200, 300...etc.) Ifyou have successfully entered DFU mode, Redsn0w will automatically begin updating thedevice with your new firmware, if not, you'll get to try again. You should see a series of eventsas following:

Begins loading the new ramdisk


21/52



Uploads the new kernel


22/52



Reboot the device

Almost done!


23/52



20. After the pineapple finishes walking across the screen, the device will reboot into a newly jailbroken system. One way to determine if your device is jail broken (and a very important part togaining the remote access we need) is the addition of the Cydia application. Because we jailbroke the phone, we were granted the ability to install applications that have not been signedand approved by the App Store.

21. Cydia is the application that we'll use to gain remote access into the internal operating systemof the device. Because the device has been jail broken, a user now has the ability to traversefrom the user space into the file system. So, from Cydia, we're going to search for and installOpenSSH. This is simply a port of the open source OpenSSH that is freely available andwidely used by the *Nix community and Windows admins.


24/52



22. Click on the Cydia icon. As it attempts to initialize, you'll likely beasked to select a WiFi network. Go ahead and configure thosesettings.

23. Cydia will then ask Who Are You?. Choose Developer (No Filters). If, after choosing

Developer, you are asked to update Cydia, simply choose to ignore.

24. Use the search function and search for OpenSSH and follow the onscreen instructions toinstall the application, by clicking install then confirm in the top right corner.

25. Next, as we noticed through dozens of reboots of our devices, sometimes the WiFi adapterdoes not activate itself properly. In order to give ourselves better access to toggle a number ofcommunication interfaces at the swipe of our finger, we chose to install SBSettings from Cydiaas well.

26. Again, using the search function in Cydia, search for SBSettings. As the search begins tofind matches, there are quite a few applications that appear that mention SBSettings. Scrolldown to find the application that is labeled, simply, SBSettings from BigBoss & Planet-iPhones (System). For Mac users, you'll notice that there is a blue icon that resembles theFinder application in OS X.

27. Install SBSettings by clicking on the application, click install and then confirm. SinceSBSettings is updating the iPhone's SpringBoard, it may take a second to reload theSpringBoard.

28. SBSettings does not include an icon on the SpringBoard to gain access to the features. Inorder to access the new toggle features, simply swipe your finger across the notifications bar atthe top of the display, from left to right. SBSettings' new toggles will drop down from thenotifications bar.


25/52



Test Cases

Once the baseline configuration was achieved and the proper process tobypass security controls was identified, the GTC defined a series of tests that would be run to testwhether ContactCrypt would adequately encrypt contact data regardless of whether the iPhonesecurity controls were in place or bypassed and whether ContractCrypt was encrypting data or not.

Changes to the system that would normally occur during the process of potentially recovering data thatshould be encrypted were broken down into steps and a backup was performed of the system.

Defining the varying degrees of change that could occur from the baseline configuration of the iPhoneresulted in 6 different test cases that would be run. Each backup instance was then analyzed todetermine whether the target contact data could be identified in the backup's raw files.

Due to research that had already been published on the Internet, it is possible to assume the results ofmany of the test cases, based upon what is already known about weaknesses in the iPhone's securitycontrols. However, for the sake of ensuring a systematic test process the GTC performed anddocumented each test case as if the outcome was unknown.

For the purposes of our testing, the GTC determined that it would be necessary to perform tests onboth the 3G and the 3G S devices at the same time. This type of testing allowed the GTC todetermine if there were any differences in the way data was handled between the two devices. Thetests that we chose to perform started with both devices configured according to the baselineconfiguration that was detailed above. Various changes were made to each device to move theconfigurations from the baseline to various levels of security provided by iPhone, iTunes andContactCrypt.

Case 1: In this test case, we are performing a backup of a newly configured 3G and 3G S device with a newcontact added. There are no security controls applied to the data.

Device Configuration: Baseline No passcode set on device Contact exists as following:

! iPhone 3G:" Name: Jane Doe" Phone#: (555) 123-0987" Organization: Testers Unlimited" Email: [email protected]" Homepage: spoon.com" Address: 90909 Broad St

Columbus, Oh 43222


26/52



! iPhone 3G S:" Name: John Smith" Phone#: (808) 444-4444" Organization: Eight-0-Eight State Inc." Email: [email protected]" Homepage: myspace.com" Address: 15151 Main St

Reynoldsburg, Oh 43312 ContactCrypt installed, but not enabled Encrypt backup setting not checked

Strings to Match: 3G: Jane, Doe 3G S: John, Smith

Expected Results: Expected to be able to grep through directory containing backup files andreceive results confirming existence of clear text strings matching each instance of the test controldata.

Results: As expected, each of the string matching commands returned results indicating that thestrings existed in some form in either the .mdinfo or .mddata raw file formats that makeup theiPhone backup. This indicates that we are able to view the contact data in clear text in both the rawdatabase file and when browsing the contacts database.

3G:

Grep commands matching strings in the backup files:


27/52




28/52



Image of the database being browsed:

3G S:



29/52




Summary: The above mentioned string matches should be expected as there is no encryption set ateither the iTunes backup encryption configuration or by ContactCrypt. What we see here is theexistence of the strings that make up the name of both contacts is visible in the backup files that arecreated when a backup is performed. Additionally, because the backup was not encrypted, we canopen the contact database file with SQLite Database Browser and view the contents.

Note: Referring to the above images that illustrate the string matching commands, notice that there is

also a match to the searched strings that applies to the DynamicDictionary-4 metadata file. This is the backup of the keyboard cache file that remembers and stores words that are inputted into the device via the keyboard. This file match will remain a constant through the remainder of the tests that are performed and does not indicate a match that applies to the specific results that are received.

Case 2:

In this test case we are performing a backup of a 3G and 3G S device that has had the iPhonepasscode and iTunes backup password set.

Device Configuration: Passcode and iTunes backup encryption enabled

Passcode enabled on handset Contact exists as following:

! iPhone 3G:" Name: Jane Doe" Phone#: (555) 123-0987" Organization: Testers Unlimited


30/52



" Email: [email protected]" Homepage: spoon.com" Address: 90909 Broad St


" Name: John Smith" Phone#: (808) 444-4444" Organization: Eight-0-Eight State Inc." Email: [email protected]" Homepage: myspace.com" Address: 15151 Main St

Reynoldsburg, Oh 43312 ContactCrypt installed, but not enabled Encrypt backup setting checked, configured to encrypt data


Expected Results: Would expect that the user is now prompted for a passcode to gain access to thehandset, upon reboot. The backup is adequately encrypted from the iTunes backup encryption settingand any attempt to match the target control data strings would fail.

Results: As expected, the iTunes encryption adequately encrypted the backup of both devices. We

are unable to match the strings that make up the contact data or browse the database file.

3G:



31/52




3G S:



Summary: Since we have enabled the passcode and encryption in iTunes, when a backup isperformed, the handset refers to the keychain-2.db file to determine whether iTunes encryption hasbeen enabled. When the device notices that a passcode has been set at the iTunes backup, thedevice encrypts the backup files when transferring them to iTunes. These backed up files are nolonger able to be searched or viewed in this state. At this point, it appears that encryption isfunctioning properly.


32/52



Case 3:

In this test case we are effectively bypassing the security applied by theiPhone passcode and the iTunes backup encryption features.

Device Configuration: Passcode and iTunes backup encryption enabled, but bypassed. Passcode enabled on handset

! security bypassed by removing the passcode record from the database located at:" /private/var/Keychains/keychain-2.db

Contact exists as following:! iPhone 3G:

" Name: Jane Doe" Phone#: (555) 123-0987" Organization: Testers Unlimited" Email: [email protected]" Homepage: spoon.com" Address: 90909 Broad St



Reynoldsburg, Oh 43312 ContactCrypt installed, but not enabled Encrypt backup setting checked, configured to encrypt data

! Enryption bypassed by removing the encryption lock record from the databaselocated at:" /private/var/Keychains/keychain-2.db


Expected Results: Would expect that upon reboot of the device, the user is no longer prompted forthe passcode to gain access to the handset. The backup encryption should be bypassed, however,iTunes would still indicate that the backup is being encrypted. Since ContactCrypt is still not enabled,the contact data should be in clear text again and attempts to match strings will succeed for each


33/52



string.

Results: As expected, each of the string matching commands returned results indicating that thestrings existed in some form in the raw file formats that makeup the iPhone backup. At this point, wesee the exact same data output that we saw in case 1 because we removed the record in the

keychain-2.db database file that tells the device to encrypt the files when performing a backup.

3G:




34/52



3G S:




35/52



Summary: Since we were able to bypass the encryption provided by setting a passcode in iTunes, weare now able to illustrate that, even though the user still believes their backups are being encrypted,we are able to view the contents of the backup files in clear text.

At this point in our testing, we would normally begin to illustrate how ContactCrypt can be employed toencrypt sensitive contact information while it resides on the handset and in backup files. However,through the many tests that were performed during the process of verifying the weaknesses iniPhone's passcode security and encryption, the GTC stumbled across another concern in the way thatthe iPhone handles deleted data.

Specifically, the GTC identified a process in the contact database that forces modifications or deletionsof contacts in the contact database to be tracked. Our analysis indicates that the process of trackingchanges to the database forces the state of the contact prior to modification to be appended to randomparts of the raw database file that are not viewable as a record in an actual database table. Below isan example.

Deleted Contact:

In this sample test case, we have deleted the contacts on the 3G and 3G S device to illustrate how theiPhone handles modified contacts in the contacts database.

Device Configuration: Passcode and iTunes bypassed Passcode enabled on handset



" Contact has been deleted from the handset using the "Contacts" application! iPhone 3G S:

" Contact has been deleted from the handset using the "Contacts" application ContactCrypt installed, but not enabled Encrypt backup setting checked, configured to encrypt data

! Enryption bypassed by removing the encryption lock record from the databaselocated at:" /private/var/Keychains/keychain-2.db


Expected Results: Since we deleted the contact, using the Contacts application on the handset, wewould expect that the contact string no longer exists on the device.


36/52



Results: An unexpected result is received at this point. When we grep thebackup files for the strings that match the contact that was just deleted, we notice that the contact datastill exists in the contact database. When we browse the database, we see no record in any of theviewable tables that indicates that the contact should still exist. However, we do notice that one table

in the database contains additional information and that is the ABPersonChanges table. This table isused to track changes to the database by the type of change that has occurred. Type0=Add,Type1=Modification, Type2=Deletion.

3G:




37/52




38/52



3G S:




39/52



Summary: As illustrated above, we have created a situation in both the 3G and the 3G S devicewhere a contact was deleted from the handset, but remains intact in the raw database file. At this

point, we believe it is due to the fact that the ABPersonChanges table is used to track changes to thedatabase file. However, even though we know changes are being tracked, there is no viewable tablein the database that allows us to view the specifics of those changes.

At this point, we will revert back to the state that both devices existed at the end of case 3 to ensurethat we are working with consistent data when we begin to implement the encryption provided byContactCrypt.

Case 4:

In test case 3 we bypassed the protections provided by iPhone and iTunes. Here we will apply

ContactCrypt encryption.

Device Configuration: Passcode and iTunes bypassed, ContactCrypt enabled and encryptingcontacts

Passcode enabled on handset! security bypassed by removing the passcode record from the database located at:

" /private/var/Keychains/keychain-2.db Contact exists as following:

! iPhone 3G:" Name: Jane Doe" Phone#: (555) 123-0987" Organization: Testers Unlimited" Email: [email protected]" Homepage: spoon.com" Address: 90909 Broad St


40/52





Reynoldsburg, Oh 43312 ContactCrypt installed and configured to encrypt contact data Encrypt backup setting checked, configured to encrypt data

! Enryption bypassed by removing the encryption lock record from the database located at:" /private/var/Keychains/keychain-2.db


Expected Results: Would expect that ContactCrypt is functioning correctly and the contact data isencrypted at the handset display, when viewing the records in the database tables, as well as in theraw database file.

Results: The results of this particular test are slightly different than what we would have expected.When viewing the contacts via the Contacts application on the handset, the user is presented withinformation that is encrypted and indiscernible. When browsing the tables of the database thatcontains the information specific to the contact, we are given the same indiscernible information thatthe user sees at the handset. However, when we match the contact strings in the raw database file,we see remnants of the phone number and email address of the contact remains. As a result of thistest, SMobile has since modified ContactCrypt and version 1.7 now removes this information from theraw database file.


41/52



3G:



42/52




3G S:



43/52




Summary: When ContactCrypt is employed, we are able to illustrate that the application adequatelyencrypts the data as it is displayed to the user and as it rests in the contact database. However, westill see remnants of the email address and phone number in the raw database file. This is due to thesame process that was mentioned in the previous example that forces modifications to the database to

be tracked and appended to the raw file.

Case 5:

This test case uses ContactCrypt to decrypt the contacts, similar to how the application would normallybe used.

Device Configuration: Passcode and iTunes bypassed, ContactCrypt decrypted Passcode enabled on handset



" Name: Jane Doe" Phone#: (555) 123-0987" Organization: Testers Unlimited


44/52



" Email: [email protected]" Homepage: spoon.com" Address: 90909 Broad St



Expected Results: For this test, we chose to decrypt the contact data from ContactCrypt. As such,we would expect that the contact data is now unencrypted in the database tables as well as in the rawdatabase file.

Results: In one sense, the results that are received are expected in that the data that was encryptednow resides in clear text. The unexpected result is that we continue to see the encrypted data,alongside the unencrypted data.


45/52



3G:



46/52





47/52



3G S:



48/52




Summary: In this test case we are able to highlight the fact that the process the iPhone employs totrack changes to the contact database forces data to remain in the raw database file when it shouldhave been deleted. In this particular case we are seeing that the encrypted data that resemblesSmobileencrypted...... remains in the raw database file while it is no longer visible in the databasetables.

Case 6:

In this test case we are going to re-encrypt the data with ContactCrypt to see how the database reactsto additional changes occurring and whether they will continue to be tracked and appended.

Device Configuration: Passcode and iTunes bypassed, original contact encrypted, new contactunencrypted.

Passcode enabled on handset! security bypassed by removing the passcode record from the database located at:

" /private/var/Keychains/keychain-2.db Contact exists as following:

! iPhone 3G:" Name: Jane Doe" Phone#: (555) 123-0987


49/52



" Organization: Testers Unlimited" Email: [email protected]" Homepage: spoon.com" Address: 90909 Broad St



Reynoldsburg, Oh 43312 ContactCrypt installed and configured to encrypt the contact data. Encrypt backup setting checked, configured to encrypt data

! Enryption bypassed by removing the encryption lock record from the database located at:" /private/var/Keychains/keychain-2.db


Expected Results: At this point, we are uncertain what results we will receive at this point. Logically,we would expect that the contact data is encrypted and is unable to be searched or viewed in thedatabase tables. However, since we began noticing that iPhone forces the database to track changesto the database and appends the clear text data to the raw file, we are unsure how it will react in thistest case.

Results:


50/52



3G:




51/52



3G S:



Summary: In this test case, we re-encrypted the contact data using ContactCrypt in an effort to seehow the database would react when it attempted to track the changes that occurred. With thisadditional step of re-encrypting the contact data, we're able to show how ContactCrypt addresses theweakness in the way that iPhone has implemented tracking change to the contacts database.ContactCrypt was specifically designed to address the process that the database uses to trackchanges and appending the state of the contact prior to the change to the raw database file.Specifically, Contact Crypt calls the encrypt function multiple times in order to overwrite the trackingdata that is appended to the database file.


52/52

SynopsisThe GTC originally set out to determine whether or not SMobile's ContactCrypt would provideadequate encryption for contacts that reside on an iPhone device, even after the iPhone and iTunesencryption capabilities had been bypassed. The GTC reproduced the process of jail breaking a devicein order to install unsigned applications and gain access to the underlying operating system of thedevice. By gaining this type of access, the GTC verified that it is a very simple process to bypass thesecurity of the iPhone and encryption of a backup performed from iTunes. The GTC was able to showthat by simply removing 2 entries in the keychain-2.db database file, it is possible to trick the deviceinto thinking that no security has been enabled. Even if a user has configured iTunes to encrypt thesystem backup, the device believes it does not have to encrypt the data as it performs the task.

During testing, the GTC was able to show that ContactCrypt succeeds in encrypting sensitive contactdata, even after iPhone's passcode and backup encryption features have been easily bypassed.During the tests, the GTC identified an additional weakness in the way that the iPhone contactdatabase handles modifications to the database. Specifically, the iPhone contact database isconfigured to track changes to the database. This process of tracking changes forces the database toappend the state of the contact prior to the modification to the raw database file, in what appears to be

a random manner, even though the data is not viewable in the database tables. This means that itcould be possible to retrieve deleted or modified contact data directly from the raw database file whenthe user believes the data has been purged. ContactCrypt 1.7 is equipped with a mechanism to purgethis data from the rawe database file

Table of Results

Test Case Configuration Expected Result Result

Case 1 Device Configuredaccording to baseline

Data in clear text in databasetable and raw file

Contact data was in clear text in rawdatabase file

Case 2 iPhone and iTunesprotections applied

No data readable in backupfiles

Files were adequately encrypted

Case 3 iPhone and iTunesprotections bypassed

Data in clear text in databasetables and raw file

Contact data was in clear text in rawdatabase file

Case 4 -iPhone and iTunesprotections bypassed-ContactCrypt 1.6enabled and encryptingdata

Data should be encrypted intables and raw file

-Database tables contained onlyencrypted data-Remnants of clear text data existed inraw file due to iPhone databasetracking

Case 5 -iPhone and iTunesprotections bypassed

-ContactCrypt notencrypting data

Data in clear text in databasetable and raw file

-Contact data was in clear text in rawdatabase file

-Remnants of encrypted data existed inraw file

Case 6 -iPhone and iTunesprotections bypassed-ContactCrypt 1 7

Data should be encrypted intables and raw file

-Data was encrypted in tables and rawdatabase file-Remnants of clear text data no longer

Documents

SMobile Global Threat Center - Analysis and Comparison of iPhone 3G, 3GS and - Contact Crypt Encryption Technologies