1 July 8, 2014 2 Tool Specification 3 4 5 6

7 Version 1.0 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

35

36

ii 5/9/16 5:49 AM

37 Abstract 38 As mobile devices proliferate, incorporating a host of integrated features and capabilities, their use 39 can be seen everywhere in our world today. Mobile communication devices contain a wealth of 40 sensitive and non-sensitive information. In the investigative community their use is not restricted to 41 data recovery alone as in criminal cases, but also civil disputes and proceedings, and their aggregate 42 use in research and criminal incident recreation continues to increase. Due to the exploding rate of 43 growth in the production of new mobile devices appearing on the market each year is reason alone 44 to pay attention to test measurement means and methods. The methods a tool uses to capture, 45 process, and report data must incorporate a broad range of extensive capabilities to meet the 46 demand as a robust data acquisition tool. In general, a forensic examination conducted on a mobile 47 device is only a small subset of the larger field of digital forensics. Consequentially, tools 48 possessing an exhaustive array of capabilities to acquire data from these portable mobile devices are 49 relatively few in number. 50 51 This specification defines requirements for mobile device applications capable of acquiring data 52 from smart phones, feature phones, tablets, Universal Integrated Circuit Cards (UICCs), and test 53 methods used to determine whether a specific tool meets the requirements for producing measurable 54 results.• Test requirements are statements used to derive test cases that define expectations of a tool 55 or application. Test cases describe the combination of test parameters required to test each assertion. 56 Test assertions are described as general statements or conditions that can be checked after a test is 57 executed. Each assertion appears in one or more test cases consisting of a test protocol and the 58 expected test results. The test protocol specifies detailed procedures for setting up the test, 59 executing the test, and measuring the test results. The associated assertions and test cases are 60 defined in the test plan document entitled: Mobile Device Tool Test Assertions and Test Plan. 61 62 Comments and feedback are welcome; revisions of this document are available for download at: 63 http://www.cftt.nist.gov/mobile_devices.htm. 64

• NIST does not endorse nor recommend products or trade names identified in this paper. All products used in this paper are mentioned for use in research and testing by NIST. iii 5/9/16 5:49 AM

65

iv 5/9/16 5:49 AM

66 TABLE OF CONTENTS 67 68 1. Introduction ...... 1 69 2. Purpose ...... 1 70 3. Scope ...... 2 71 4. Definitions ...... 2 72 5. Background ...... 4 73 5.1 Mobile Device Characteristics – Internal Memory ...... 4 74 5.2 UICC Characteristics ...... 5 75 5.3 Digital Evidence ...... 5 76 5.4 Test Methodology ...... 5 77 6. Requirements ...... 6 78 6.1 Requirements for Core Features ...... 6 79 6.2 Requirements for Optional Features ...... 6 80 6.2.1 UICC Acquisition ...... 7 81 6.2.2 Data Integrity ...... 7 82 6.2.3 Password Protected UICCs ...... 7 83 6.2.4 PIN Attempts ...... 7 84 6.2.5 PUK Attempts ...... 7 85 6.2.6 Physical Acquisition ...... 7 86 6.2.7 Non-ASCII Characters ...... 7 87 6.2.8 Stand-alone Acquisition ...... 7 88 6.2.9 Hashing ...... 7 89 6.2.10 GPS Coordinates ...... 8 90 91

v 5/9/16 5:49 AM

92

vi 5/9/16 5:49 AM

93 1. Introduction 94 The need to ensure the reliability of mobile device forensic tools intensifies, as the embedded 95 intelligence and ever-increasing storage capabilities of mobile devices expand. The goal of the 96 Computer Forensic Tool Testing (CFTT) project at the National Institute of Standards and 97 Technology (NIST) is to establish a methodology for testing computer forensic tools. This 98 is accomplished by the development of both specific and common rules that govern tool 99 specifications. We adhere to a disciplined testing procedure, established test criteria, test sets, and 100 test hardware requirements, that result in providing necessary feedback information to toolmakers 101 so they can improve their tool’s effectiveness; end users benefit in that they gain vital information 102 making them more informed about choices for acquiring and using computer forensic tools, and 103 lastly, we impart knowledge to interested parties by increasing their understanding of a specific 104 tool’s capability. Our approach for testing computer forensic tools is based on established well- 105 recognized international methodologies for conformance testing and quality testing. For more 106 information on mobile device forensic methodology please visit us at: www.cftt.nist.gov. 107 108 The Computer Forensic Tool Testing (CFTT) program is a joint project of the National Institute of 109 Justice (NIJ), the research and development organization of the U.S. Department of Justice, and the 110 National Institute of Standards and Technology’s (NIST’s) Law Enforcement Standards Office 111 (OLES) and Information Technology Laboratory (ITL). CFTT is supported by other organizations, 112 including the Federal Bureau of Investigation, the U.S. Department of Defense Cyber Crime Center, 113 U.S. Internal Revenue Service Criminal Investigation Division Electronic Crimes Program, U.S. 114 Department of Homeland Security’s Bureau of Immigration and Customs Enforcement, U.S. 115 Customs and Border Protection, and the U.S. Secret Service. The objective of the CFTT program is 116 to provide measurable assurance to practitioners, researchers, and other applicable users that the 117 tools used in computer forensics investigations provide accurate results. Accomplishing this 118 requires the development of specifications and test methods for computer forensics tools and 119 subsequent testing of specific tools against those specifications. 120 121 The central requirement for a sound forensic examination of digital evidence is that the original 122 evidence must not be modified (i.e., the examination or capture of digital data from a mobile device 123 and associated media must be performed without altering the device or media content). In the event 124 that data acquisition is not possible using current technology to access information without 125 configuration changes to the device (e.g., loading a driver), the procedure must be documented. 126

127 2. Purpose 128 This specification defines requirements for mobile device forensic tools used in digital forensics 129 capable of acquiring internal memory from smart phones, feature phones, tablets and associated 130 media i.e., Universal Integrated Circuit Cards (UICCs). 131 132 The mobile device tool requirements are used to derive test assertions. The test assertions are 133 described as general statements of conditions that can be checked after a test is executed. Each 134 assertion generates one or more test cases consisting of a test protocol and the expected test results. 135 The test protocol specifies detailed procedures for setting up the test, executing the test, and 136 measuring the test results.

137 3. Scope 138 The scope of this specification is limited to software tools capable of acquiring the internal memory 139 of smart phones, feature phones, tablets and UICCs. The mobile device tool specification is general 140 and capable of being adapted to other types of mobile device forensic software. 141

142 4. Definitions 143 This glossary was added to provide context in the absence of definitions recognized by the 144 computer forensics community. 145 Associated data: Multi-media data (i.e., graphic, audio, video) that are attached and delivered via a 146 multi-messaging service (MMS) message. 147 Acquisition File: A snapshot of data contained within the internal memory of a target mobile 148 device (e.g., feature phone, smart phone, tablet) or associated media i.e., UICC. 149 Case File: A file generated by a forensic tool that contains the data acquired from a mobile device 150 or associated media and case-related information (e.g., case number, property/evidence number, 151 agency, examiner name, contact information, etc.) provided by the examiner. 152 CDMA: Code Division Multiple Access describes a communication channel access method that 153 employs spread-spectrum technology and a special coding scheme. 154 CHV: Card Holder Verification is a personal identification number (PIN) that provides access to a 155 Universal Integrated Circuit Card (UICC). 156 CDMA Subscriber Identity Module (CSIM) – CSIM is an application to support CDMA2000 157 phones that runs on a UICC, with a file structure derived from the R-UIM card. 158 Data Objects: Files or directories stored in the internal memory of the device or UICC such as 159 address book entries, Personal Information Management data, call logs, text messages, stand- 160 alone files (e.g., graphic files, audio, video). 161 Electronic Serial Number (ESN): ESNs were issued until 2005, which uniquely identified CDMA 162 phones. An ESN number consist of a 32-bit alphanumeric string that allowed a maximum of 4 163 billion unique numbers. 164 Enhanced Message Service (EMS): Text messages over 160 characters or messages that contain 165 either Unicode characters or a 16x16, 32x32 black and white image. 166 Feature phone: A device whose major function is primarily handling incoming/outgoing phone 167 calls over a wireless network (e.g., GSM, CDMA) with limited task management applications. 168 : Non-volatile memory that retains data after the power is removed. 169 Global Positioning System (GPS): A navigational system involving satellites and computers that 170 can determine the latitude and longitude of a receiver. 171 Global System for Mobile Communications (GSM): An open, digital cellular technology for 172 transmitting mobile voice and data services. 173 Hard reset: The process used to reboot the smart phone returning the device back to the initial 174 factory install state, potentially erasing all user data (e.g., contacts, tasks, calendar entries).

Page 2 of 8

175 Hashing: The process of using a mathematical algorithm against data to produce a numeric value 176 that is representative of that data. 177 Human-readable format: Acquired data shown in a human language rather than binary data. 178 IM: Internal Memory. Volatile and non-volatile storage space for user data. 179 Logical acquisition: Implies a bit-by-bit copy of logical storage objects (e.g., Address book, 180 Personal Information Management data, Call logs, text messages, stand-alone data files) that 181 reside on a logical store (e.g., a file system partition). 182 Mobile Equipment Identity (MEID): An ID number that is globally unique for CDMA mobile 183 phones that identifies the device to the network and can be used to flag lost or stolen devices. 184 Mobile Subscriber International Subscriber Directory Number (MSISDN): The MSISDN is 185 the telephone number assigned to the subscriber for receiving calls on the phone. 186 Messaging Service (MMS) message: Provides users with the ability to send text 187 messages containing multimedia objects (i.e., graphic, audio, video). 188 Personal Information Management (PIM) data: Data that contains personal information such as: 189 calendar entries, to-do lists, memos, reminders, etc. 190 Physical acquisition: A bit-by-bit acquire of the mobile device internal memory. 191 PIN: A Personal Identification Number that is 4 to 8 digits in length used to secure mobile devices 192 from unauthorized access. 193 Preview pane: Section of the (GUI) that provides a snapshot of the 194 acquired data. 195 PUK: A Personal Unblocking Key used to regain access to a locked mobile device whose PIN 196 attempts have been exhausted. 197 Recoverable data objects: Logically deleted data objects that have not been overwritten. 198 Short Message Service (SMS): A service used for sending text messages (up to 160 characters) to 199 mobile devices. 200 Smart phone: A full-featured that provides users with like 201 functionality by incorporating PIM applications, enhanced connectivity and email 202 operating over an supported by accelerated processing and larger storage 203 capacity compared with present cellular phones. 204 MDT: Mobile Device Tool. A tool capable of acquiring the internal memory from a smart phone, 205 feature phone, tablet or UICC. 206 Removable User Identity Module (R-UIM) – A card developed for cdmaOne/CDMA2000 207 handsets that extends the GSM SIM card to CDMA phones and networks. 208 Stand-alone data: Data (e.g., graphic, audio, video) that is not associated with or has not been 209 transferred to the device via email or MMS message. 210 Subscriber Identity Module (SIM): A smart card that contains essential subscriber information 211 and additional data providing network connectivity to mobile equipment operating over a GSM 212 network.

Page 3 of 8

213 Supported Data Objects: Data objects (e.g., subscriber information, PIM data, text messages, 214 stand-alone data, MMS messages and associated data) that the cellular forensic tool has the 215 ability to acquire according to the cellular forensic tool documentation. 216 Tablet: A Tablet PC is a PC equipped with a stylus or a touchscreen. This form factor is 217 intended to offer a more mobile PC. 218 Universal Integrated Circuit Card: An integrated circuit card that securely stores the international 219 mobile subscriber identity (IMSI) and the related cryptographic key used to identify and 220 authenticate subscribers on mobile devices. A UICC may be referred to as a: SIM, USIM, R-UIM 221 or CSIM, and is used interchangeably with those terms. 222 UMTS Subscriber Identity Module (USIM) – A module similar to the SIM in GSM/GPRS 223 networks, but with additional capabilities suited to networks. 224 User data: Data populated onto the device using mobile device default applications. 225

226 5. Background 227 228 5.1 Mobile Device Characteristics – Internal Memory 229 Mobile devices typically contain one or two different types of non-volatile flash memory. These 230 types are NAND and NOR. NOR flash has slower read/write times and is nearly immune to 231 corruption and bad blocks while allowing random access to any memory location. NAND flash 232 offers higher memory storage capacities, is less stable and only allows sequential access. 233 234 Memory configurations among mobile devices have evolved over time. Feature phones were 235 among the first types of devices that contained NOR flash and RAM memory. System and user 236 data are stored in NOR and copied to RAM upon booting for faster code execution and access. This 237 is known as the first generation of mobile memory configurations. 238 As were introduced, memory configurations evolved, adding NAND flash memory. 239 240 This arrangement of NOR, NAND and RAM memory is referred to as the second generation. This 241 generation of memory configurations stores system files in NOR flash and user files in NAND; 242 RAM is used for code execution. The latest smartphones contain only NAND and RAM memory 243 (i.e., third generation), due to higher transaction speed, greater storage density and lower cost. 244 245 Although data present on mobile devices may be stored in a proprietary format, forensic tools 246 tailored for mobile device acquisition should minimally be able to perform a logical acquisition for 247 supported devices and provide a report of the data present in the internal memory. Tools that 248 possess a low-level understanding of the proprietary data format for a specific device may provide 249 examiners with the ability to perform a physical acquisition and generate reports in a meaningful 250 (i.e., human-readable) format. 251

Page 4 of 8

252 5.2 UICC Characteristics 253 Due to the GSM 11.111 standard, mobile device forensic tools designed to extract data from a UICC 254 either internally or with an external Personal Computer/Smart Card (PC/SC) reader, should be able 255 to properly acquire, decode, and present data in a human-readable format. An abundance of 256 information is stored on UICCs such as Abbreviated Dialing Numbers (ADNs), Last Numbers 257 Dialed (LND), SMS messages, subscriber information (e.g., IMSI), and location information (i.e., 258 Location Information [LOCI], General Packet Radio Service Location [GPRSLOCI]). 259 260 5.3 Digital Evidence 261 The amount and richness of data contained on mobile devices vary based upon the manufacturer 262 and OS. Pre-loaded applications and the ability to install customized applications provide users with 263 endless solutions. However, there is a core set of data that computer forensic tools can recover that 264 remains somewhat consistent across the majority of mobile devices. Tools should have the ability to 265 recover the following data objects stored in the device’s internal memory and associated media: 266 • International Mobile Equipment Identifier (IMEI) – GSM device memory 267 • Mobile Equipment Identifier (MEID) / Electronic Serial Number (ESN) – CDMA device 268 memory 269 • Service Provider Name (SPN) – UICC memory 270 • Integrated Circuit Card Identifier (ICCID) – UICC memory 271 • International Mobile Subscriber Identity (IMSI) – UICC memory 272 • Mobile Subscriber International ISDN Number (MSISDN) – UICC memory 273 • Personal Information Management (PIM) data - (e.g., Address book, Calendar entries, to-do 274 list, Tasks, Memos) – device memory 275 • Abbreviated Dialing Numbers (ADNs) – UICC memory 276 • Call logs – Incoming and outgoing calls – device memory 277 • Last Numbers Dialed (LND) – UICC memory 278 • Text messages (SMS, EMS) – device memory, UICC memory 279 • Multi-media Messages (MMS)/email - and associated data (i.e., audio, graphics, video) – 280 device memory 281 • Application data - (e.g., Word documents, spreadsheet data, presentation data, etc.) – device 282 memory 283 • File storage - Stand-alone files such as audio, graphic and video – device memory 284 • Internet data - (e.g., bookmarks, visited sites, cached URLs) – device memory 285 • Social media related data - (e.g., facebook, twitter, Linkedin, Instagram) – device memory 286 • GPS related data - Longitude and latitude coordinates – device memory 287 288 5.4 Test Methodology 289 To provide repeatable test results, the following test methodology is strictly followed. Each forensic 290 application under evaluation is installed on a dedicated (i.e., no other forensic applications are 291 installed) host computer operating with the required platform as specified by the application. The 292 internal memory of the source device and UICC is populated with a known dataset. Source devices

1 http://www.ttfn.net/techno/smartcards/gsm11-11.pdf Page 5 of 8

293 are stored in a protected state subsequent to initial data population, thus eliminating the possibility 294 of data modification due to network connectivity. 295 296 The following data objects (if supported) are used in populating the internal memory of the mobile 297 devices: address book, PIM data, application data, Internet data, call logs, text messages (SMS, 298 EMS), MMS messages/email with attachments (i.e., audio, graphic, video), stand-alone data files 299 (i.e., audio, graphic, video), social media related data and GPS coordinates. 300 301 The following data objects are used for populating the UICC: Abbreviated Dialing Numbers 302 (ADNs), Last Numbers Dialed (LND), Short Messaging Service (SMS) messages – (marked as 303 Read, Unread and Deleted) and EMS messages.

304 6. Requirements 305 The mobile device tool requirements are in two sections: 6.1 and 6.2. Section 6.1 lists requirements 306 i.e., Mobile Device Tool-Core Requirement-01, MDT-CR-01 through MDT-CR-04 that all 307 acquisition tools shall meet. Section 6.2 lists requirements i.e., Mobile Device Tool-Requirement 308 Optional-01, MDT-RO-01 through MDT-RO-11 that the tool shall meet on the condition that 309 specified features or options are offered by the tool. 310 311 6.1 Requirements for Core Features 312 All mobile device forensic tools capable of acquiring the internal memory of a mobile device shall 313 meet the following core requirements. 314 315 MDT-CR-01 A mobile device forensic tool shall have the ability to recognize supported devices 316 via the vendor-supported interfaces (e.g., cable, Bluetooth, Infrared). 317 MDT-CR-02 A mobile device forensic tool shall have the ability to notify the user of connectivity 318 errors between the device and application during acquisition. 319 MDT-CR-03 A mobile device forensic tool shall have the ability to provide the user with either a 320 preview pane or generated report view of data acquired. 321 MDT-CR-04 A mobile device forensic tool shall have the ability to logically acquire all application 322 supported data objects present in internal memory without modifying the data objects present on 323 the device. 324

325 6.2 Requirements for Optional Features 326 The following mobile device tool requirements define optional tool features. If a tool provides the 327 capability defined, the tool is tested for conformance to these requirements. If the tool does not 328 provide the capability defined, the requirement does not apply. 329 330 The following optional features are identified: 331 • UICC acquisition 332 • Data Integrity 333 • Password-protected UICCs 334 • PIN/PUK input 335 • Physical acquisition

Page 6 of 8

336 • Non-ASCII character support 337 • Hashing 338 • GPS Coordinates

339 6.2.1 UICC Acquisition 340 MDT-RO-01 A mobile device forensic tool shall have the ability to recognize supported UICCs via 341 the vendor supported interface (e.g., PC/SC reader, proprietary reader, internal). 342 MDT-RO-02 A mobile device forensic tool shall have the ability to notify the user of connectivity 343 errors between the UICC reader and application during acquisition. 344 MDT-RO-03 A mobile device forensic tool shall have the ability to acquire all application- 345 supported data objects present in the UICC memory.

346 6.2.2 Data Integrity 347 MDT-RO-04 A mobile device forensic tool shall have the ability to protect previously acquired 348 data objects within a saved case file from modification.

349 6.2.3 Password Protected UICCs 350 MDT-RO-05 A mobile device forensic tool shall have the ability to provide the user with the 351 ability to unlock a password protected UICC before acquisition.

352 6.2.4 PIN Attempts 353 MDT-RO-06 A mobile device forensic tool shall have the ability to present the remaining number 354 of CHV1/CHV2 PIN unlock attempts.

355 6.2.5 PUK Attempts 356 MDT-RO-07 A mobile device forensic tool shall have the ability to present the remaining number 357 of PUK unlock attempts.

358 6.2.6 Physical Acquisition 359 MDT-RO-08 A mobile device forensic tool shall have the ability to perform a physical acquisition 360 of the device’s internal memory for supported devices.

361 6.2.7 Non-ASCII Characters 362 MDT-RO-09 A mobile device forensic tool shall have the ability to present data objects containing 363 non-ASCII characters acquired from the internal memory of the mobile device or UICC. Non- 364 ASCII characters shall be printed in their native representation.

365 6.2.8 Stand-alone Acquisition 366 SPT-RO-10 A mobile device forensic tool shall have the ability to acquire internal memory data 367 without modifying data present on the UICC.

368 6.2.9 Hashing 369 MDT-RO-11 A mobile device forensic tool shall have the ability to compute a hash for individual 370 data objects.

Page 7 of 8

371 6.2.10 GPS Coordinates 372 MDT-RO-12 A mobile device forensic tool shall have the ability to acquire GPS related data 373 present in the internal memory. 374

Page 8 of 8