Draft based Audio Recorder Technical Requirements DJF-16-1200-N-0007 Smartphone-based Audio Recorder Draft Technical Requirements Engineering Research Facility. Quantico, VA 29 July, 2015 Draft Smartphone based Audio Recorder Technical Requirements RFI Dra? Smartphone based Audio Recorder Technical Requirements RFI DJ F- 6? 1 ZOU-N-UDOT Smartphone-based Audio Recorder Technical Requirements 1. Background This document describes the technical requirements for covert, evidentiary audio collection from smartphones. The term "Smartphone" refers to cellular phones that have the hardware and an operating system that are able to run apps to record audio using the built-in microphone, store that data locally, and stream that audio over a data connection in near real-time. This app will allow the phone to be placed into a stealth mode, either by the user of the phone, or remotely by the controller ofthe phone. In this mode, the room audio will be streamed to another device for livelpost monitoring. The basic capability will be audio, but GPS location information is also desired and eventually video capability. This app will run on an Android, or Windows environment. The phone will operate normally. It will be possible to install the app without having to "jailbreak" the phone. Thus, the app turns the phone into a covert recorder to surreptitiously capture audio and video while also allowing live monitoring. In addition to the above, the app will also allow the phone to be used overtly as an audio/video recorder for capturing interviews. Thus, the Agent can use the phone as a field audio/video recorder when access to standard interview rooms and equipment is not feasible. 2. CONOP The CONOP involves two scenarios. The first is covert live audio collection from a con?gured cellular phone. The second is an overt collection of audio and video during an interview (Le. simply use the phone as a recorder}. For scenario number one, the app would be preloaded onto the phone and run covertly in the background. When the app is running, a person controlling the scenario will be able to remotely enable recording, effectively turning the phone into a local microphone/recorder. The recording will be stored on the phone and simultaneously the live audio will be sent (via the cellular network} to a Government owned server located in Quantico, Virginia. The storage and transfer of data will happen automatically with no user action required. For scenario number two, the app would be preloaded onto the phone. The person carrying the phone would launch the app and overtly record audio and video for a consensual, one-on-one interview. The video feed of the interviewee will be presented to the interviewer on the screen. The recording will be made on the phone. After the recordingis} has been made, the user will initiate an upload ofthe files (via the cellular Draft Smartphone based Audio Recorder Technical Requirements RFI DJF-lti-1200-N-0007r Draft Smartphone based Audio Recorder Technical Requirements DJF-16-1200-N-0007 network) to a Government-owned server. Th at process will happen automatically with no need for the agentj'user to configure network settings. General principle: any electronic data intended to be admitted in court as evidence will have a traceable "chain of custody? and procedures to en5ure it has not been altered or tampered with. This app shall contain technical safeguards designed to protect the stored evidence. While authentication hash is required, is not necessary, as the recorders do not store classified information. 3. Basic Requirements This section lists the minimum technical requirements for meeting the two concepts of operation. The main deliverable for this effort is the app which shall be compatible with Android, and Windows platforms, and the server-side software necessary for receiving the data. The app shall have two main functions: live monitor and interview recorder. Upon loading the app, the user shall have the option of selecting between these two modes. Each Concept of Operation (ConOp) will be covered in its own section. 3.1. ConOp #1 {Live Monitoring} Application Requirements Following are specific technical requirements pertaining to use of the Smartphone for covert, live monitoring. 3.1.1 Live Monitor The live monitor ConOp shall have three roles: one is the phone that sends out the data (the recorder}, one is a phone that can receive the data and listen in (a listener), and one is a phone that can remotely control the sending phone (a controller}. 3.1.1.1 The controller shall have control over the operation. The controller shall be able to turn the audio and GPS location transmissions on and off. 3.1.1.2 The recorder shall also have the capability to turn the audio and GPS location transmissions on and off. 3.1.1.3 Any listener shall only have the capability of monitoring the audio andfor GPS transmission when enabled. 3.1.1.4. The controller shall have the ability to set the phone to send audio, video, and/or GPS data without storing it on the phone or server. This is intended for an Draft Smartphonc based Audio Recorder Technical Requirements Draft Smartphone based Audio Recorder Technical Requirements RFI DJF-16-1200-N-0007 "officer safety" scenario, and to allow for live minimization when required by court order. 3.1.2 Operation Start Up 3.1.2.1 The live monitor app shall open when selected by the user. 3.1.2.2 Every user shall be prompted to enter a pre-arranged authorization code, before the operation can start. This operation code(s) shall be predetermined bv the vendor and shall be unique for each new operation. 3.1.2.3 The unique code shall be required for any other phone to join the operation. Once entered, the code is confirmed with the controller unit for user authorization. 3.1.2.4 Once a user has been granted access to an operation, that user shall be required to select a recorder or listener role. 3.1.2.5 Only one recorder shall be permitted per operation. 3.1.3 Monitoring 3.1.3.1 The app shall stream the audio over the cellular network to a Bureau controlled server. 3.1.3.2 Any user shall be able to listen to the audio and monitor the target location via GPS to a displayed map. {The displayed map can be Google Maps.) 3.1.4 Recording Requirements The app shall record the audio on the target phone (?recorder?) and also stream the audio to a Government server with a public-facing IP address. 3.1.4.1 The audio streaming shall be accomplished via the cellular network. 3.1.4.2 The audio shall be saved on the recorder in an uncompressed or lossless manner. 3.1.4.3 The audio files shall be stored in standard WAV format. 3.1.4.4 The recorder shall sample audio at 16 bits. 3.1.4.5 All files shall be date and time stamped. Draft Smartphone based Audio Recorder Technical Requirements DJF-16-1 Draft Smartphone based Audio Recorder Technical Requirements RFI 3.1.4.6 There shall be no way to edit recordings on the phone. 3.1.4.7 Once the on board memory is full, recording shall stop so there is no loss of already-recorded data. 3.1.4.8 If the memory is full, streaming of audio shall continue if network coverage is available. 3.1.4.9 If the memory is full, an alert shall be sent to all other devices in the operation that the memory is full. 3.1.4.10 The app shall implement a hash function such that all recorded data can be authenticated. Calculation of the hash shall be performed on the phone. This calculation can be done at the time of recording, the time the file is closed out, or at the time the transfer to the server is initiated, at the vendor?s discretion, to minimize battery drain. 3.1.4.11 The hash algorithm shall be or SHA-256. Reference: 0 Secure Hash Standard, FIPS Publication 180-4, dated 6 March 2012, available at: 3.1.4.12 The hash message shall be saved in an associated XML metadata file that will be uploaded along with the recordings. 3.1.4.13 The vendor shall implement a data transfer method that ensures that the data on the recorder exactly matches, bit for bit, the data transferred into the server. 3.1.4.14 The recorder phone shall not erase the data after it is transferred without a separate, deliberately initiated, on the part of the user. 3.1.5 Graphic User Interface 3.1.5.1 The software shall emphasize simplicity and ease of use. 3.1.5.2 Controls which are administrative or seldom used shall be hidden from the main user screen. 3.1.5.3 The main screen on the controller, shall at a minimum, have a map showing the transmitter location and whether data is being received. 3.1.5.4 The map shall be scalable by user using two fingers on the touch screen. Draft Smartphone based Audio Recorder Technical Requirements RFI Draft Smartphone based Audio Recorder Technical Requirements 3.1.5.5 While in live audio mode, the phone being used as a covert recorder shall have a means to hide the fact that it is recording and streaming audio. The vendor can implement this as a fake app, or a hidden app that requires a special input {like a pattern of taps or swipes] to bring it into view, or some other method, at its discretion. 3.2 ConOp #2 {Interview Recorder) Application Requirements Following are specific technical requirements pertaining to use ofthe Smartphone for overt recording of interviews by a law enforcement official. 3.2.1 Interview Recorder - The interview recorder ConOp shall have a single user designation: interviewer. 3.2.1.1 The user shall have the capability to start and stop the recording. 3.2.1.1.1 The app shall give an audible indication when recording has begun and stopped. 3.2.1.2 The user shall have the capability to end the session, thereby prohibiting any further recording on that session. 3.2.1.3 The user shall have the ability to play back the interview. 3.2.1.4 Upon start up, the app shall offer an interview function. 3.2.1.5 The user shall be prompted to enter a case number. 3.2.1.6 Start, pause and stop buttons shall be displayed after a case number is entered. 3.2.1.7 The recorder shall record audio at 16 bits or resolution [unless the phone hardware does not support this, then use the highest possible resolution). 3.2.1.8 Video shall be stored and uploaded using Motion JPEG andfor H.264IMPE64 AVC (assuming the phone supports this). 3.2.1.9 Video recording frame rate will be determined by the hardware available on the phone. 30 frames per second is preferred. The app should support the best possible quality available from the phone. 3.2.1.10 The video should be saved at resolutions of 640x480 at minimum. Note that high resolution is not necessary, and wastes bandwidth and battery life. Draft Smartphone based Audio Recorder Technical Requirements RFI DJF-16-1200-N-0007 Draft Smartphone based Audio Recorder Technical Requirements DJF- 3.2.1.11 The video picture shall appear on the phone. 3.2.1.12 The video shall have time, date and case number superimposed on the video. 3.2.1.13 The video and audio streams/files shall remain to an accuracy of 33 msec throughout the duration ofthe recording. 3.2.1.14 The clock shall count in real time. 3.2.1.15 The software shall emphasize simplicitv and ease of use. 3.2.1.15 Controls which are administrative or seldom used shall be hidden from the main user screen. 3.2.1.17 For playback the main screen, shall at a minimum, display the video with play and stop buttons. 3.2.1.18 It shall be possible, using a slide line, to skip video to any part of the recording for quick review. 3.2.1.19 The app shall implement a hash function such that all recorded data can be authenticated. Calculation of the hash shall be performed on the phone. This calculation can be done at the time of recording, the time the file is closed out, or at the time the transfer to the server is initiated, at the vendor?s discretion. 3.2.1.20 The hash algorithm shall be or SHA-256. Reference: 0 Secure Hash Standard, FIPS Publication 180-4, dated 6 March 2012, available at: 3.3 Server-side Requirements The phone and its app is only halfthe system. The other half is a web-facing server that will reside in a secure, Government-owned Space. Note that at that point, the data officially becomes ?evidence,? therefore, manv ofthe following requirements pertain to the specific file format and metadata that the files must have. It is likely that the Government will want to obtain server software from the vendor, and will install and maintain that server after the software has gone through testing and a security accreditation process. 3.3.1 Operational Metadata Draft Smartphone based Audio Recorder Technical Requirements RFI Draft Smartphone based Audio Recorder Technical Requirements DJ 3.3.1.1. The server will run software that allows fOr a Super controller {which is different from the server admin} to manage the operational codes {ref 3.1.1. above). 3.3.1.2. At the time an operation is set up, the controller will have the ability to request an operational code. He will be required at that time to enter case-related metadata that the server will associate with the operational code. 3.3.1.3. The user of the recorder phone shall be asked to input certain information that will be transmitted along with the audio files as metadata. This will be processed by the server prior to issuing an operational code. The specific information will be provided to the vendor as GFI (Government Furnished Information], but will be similar to this: 0 Field Office: enter the field office location 0 Case Number: enter up to 8 alphanumeric characters 0 Property Number: enter an 8 alphanumeric inventory control number 0 Comments: freeform text for user notes {optional input) 3.3.1.4 The system shall provide appropriate metadata in a specified XML schema. (Note the specific fields used in the Schema will probava change over time, but will be formally specified and provided to the vendor as GFI.) 3.3.2 File Delivery 3.3.2.1. The server software shall package and deliver the recordings and recording metadata inside a ZIP container. Each ZIP container will correspond to a single recording. We will work with the vendor to determine whether long recording sessions should be broken into smaller files (due, for example, to cellular network limitations) and how these would be aggregated into a single container. 3.3.2.2. The server will use SFTP (Secure File Transfer Protocol} to transfer the ZIP containers to a "watch folder? on another server on a Government network. 3.3.2.3 The server shall name each ZIP container with a speci?c format to be provided as GFI. 3.3.2.4 Each media file, GPS log file, and metadata file within the ZIP container shall have a file name that conforms to a specific format to be provided as GFI. 3.3.2.5 Each individual recording made on the phone and its metadata shall be placed in its own ZIP container. Thus, each ZIP container shall contain exactly the following four files: the media file (.WAV, etc), the related metadata ?le (.XML), the GPS data file (.CSV, .KML, etc.) and a text ?le with the SHA hash message. Draft Smartphone based Audio Recorder Technical Requirements RFI Draft Smartphone based Audio Recorder Technical Requirements RFI DJF-16-1200-N-0007 3.3.2.6 The ZIP container shall be packaged using a method that can be extracted by pkzip (which is incorporated in Windows 7 and later}. It shall n_ot be compressed, however. ZIP is merely being used as a commercial standard container. 3.4 Manual transfer of files off phone 3.4.1. Automated transfers of data from the phone to the server are preferred. However, there are situations in which this might not be possible for some reason. In those cases, there shall be a method for a trained, authorized user to transfer recordings directly off the phone. 3.4.2. The preferred method is via simple USB connection of the phone to a PC, which is mounted, and normal Windows file explorer operations. The user will need to know where the app stores the files. 3.4.3. The files will be with the password {key} the same as the operational code. 3.5 Support 3.5.1 Software Modifications 3.5.1.1 The vendor shall update the app for each platform Android, as needed, to ensure compatibility and functionality is maintained as the operating systems change and evolve. 3.5.1.2 The phone app updates shall be implemented yearly, at a minimum. 3.5.1.3 The vendor shall have a procedure to perform the app update without need of "jailbreaking" the phone. An example of how to do this is to make the app available for download via an app store (examples: iTunes store, Google Play Store). 3.5.2 Training 3.5.2.1 The Contractor shall provide in-depth training to as many as 10 Government technical personnel covering operation and testing of the software. The primary goal of the training is to enable the 10 to provide detailed support to many end users. They must be able to troubleshoot problems and have intimate knowledge of the design of the software. Draft Smartphone based Audio Recorder Technical Requirements Draft Smartphone based Audio Recorder Technical Requirements DJ F-l 6-1 200-N-0007 3.5.2.2 This training will be in the form of a briefing and informal, hands-on demonstrations that can be performed at the Contractor's location. 3.5.2.3 Any documents used in the training shall be provided as a deliverable to the COR. 3.5.2.4 The vendor shall also prepare video tutorials describing all features of the software for both users and administrators. 3.5.3 Legal support 3.5.3.1 On occasion, the authenticity of an evidentiary recording is questioned in court, and someone must be put on the stand to answer detailed technical questions about the audior?video collection. ReSponses to this scenario are provided by trained Government personnel whenever possible. Typically the response is for the vendor to sign an affidavit that addresses the speci?c question raised, and only that question. There is a remote possibility that an affidavit is insufficient and a vendor representative could be subpoenaed to appear in person to provide court testimony. Generally this involves giving a technical or scientific explanation of the collection technique with the goal of establishing or ruling out the possibility of tampering. Any vendor-proprietary information can be protected with limited dissemination, proprietary markings, and need to know. In fact, the Government works diligently to limit and control who has access to these details as they c0uld be used against us. Historically these scenarios occur no more than 3 times per year. The vendor must agree to this possibility and provide a point of contact {must be a US Citizen) who can support such a request. 3.5.3.2 The vendor will be asked to support a security accreditation process on the server. This means the code on both the phone app and the server will be examined, and the system behavior tested, by Government personnel. The purpose is to prove that data transfers go only from the phone to the server and only from the server to the specified network address, and to no other location or IP address. The support required from the vendor for this accreditation process could be as minimal as answering questions, to at most submit source code, explain its operation, and correct deficiencies that may be discovered. It is assumed this might involve proprietary information and non disclosure agreements. 3.5.4 Warranties and Maintenance 3.5.4.1. The vendor should describe the warranty terms available for this product. 3.5.4.2. The Contractor shall make available a list of technical points of contact that can be called or e-mailed during normal business hours (approximately by Government personnel. Draft Smartphonc based Audio Recorder Technical Requirements RFI DJF-16-1200-N-0007 10