CA2609469A1 - Digital evidence bag - Google Patents
Digital evidence bag Download PDFInfo
- Publication number
- CA2609469A1 CA2609469A1 CA002609469A CA2609469A CA2609469A1 CA 2609469 A1 CA2609469 A1 CA 2609469A1 CA 002609469 A CA002609469 A CA 002609469A CA 2609469 A CA2609469 A CA 2609469A CA 2609469 A1 CA2609469 A1 CA 2609469A1
- Authority
- CA
- Canada
- Prior art keywords
- evidence
- data
- file
- digital
- files
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims abstract description 60
- 238000012545 processing Methods 0.000 claims description 8
- 238000013481 data capture Methods 0.000 claims description 4
- 230000005540 biological transmission Effects 0.000 claims description 2
- 238000013500 data storage Methods 0.000 claims description 2
- 238000004458 analytical method Methods 0.000 abstract description 34
- 230000008569 process Effects 0.000 description 18
- 238000013459 approach Methods 0.000 description 15
- 238000011835 investigation Methods 0.000 description 10
- 238000003384 imaging method Methods 0.000 description 9
- 208000010975 Dystrophic epidermolysis bullosa Diseases 0.000 description 8
- 208000004298 epidermolysis bullosa dystrophica Diseases 0.000 description 8
- 230000006870 function Effects 0.000 description 7
- 238000013474 audit trail Methods 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 101150047304 TMOD1 gene Proteins 0.000 description 1
- 230000002730 additional effect Effects 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000005336 cracking Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000011842 forensic investigation Methods 0.000 description 1
- 238000010191 image analysis Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000015654 memory Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000010845 search algorithm Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Operations Research (AREA)
- Economics (AREA)
- Marketing (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Data structures, methods, programs for computers, apparatus and systems for capturing, and analysing digital data, especially in the context of digital evidence gathering and analysis. Digital evidence is captured in digital evidence bags having an index file and one or more evidence units, the evidence units each comprising an index file and an evidence file. The evidence files contain copies of raw captured data whilst the associated index files contain text details of the contents and structure of the evidence files. The tag file contains data descriptive of the source and/or provenance of the evidence units and/or the digital evidence bag as a whole. Index information and evidence data may be in the same or distinct files.
Description
DIGITAL EVIDENCE BAG
FIELD OF THE INVENTION
The present invention relates to apparatus, methods, data structures, and programs for computers for digital evidence gathering, tracking, and analysis and systems incorporating the same.
BACKGROUND TO THE INVENTION
In the world of law enforcement when a crime scene is visited in the course of an enquiry or investigation, the law enforcement officers use bags and seals to store items of evidence that are found which are considered relevant at the time. The item would then be placed into a bag which is sealed at the scene. The seal number is recorded and a tag is attached which may include details such as:
= Investigating Agency / Police Force;
= Exhibit reference number;
= Property reference number;
= Case/Suspect name;
= Brief description of the item;
= Date and time the item was seized/produced;
= Location of where the item was seized/produced;
= Name of the person that is producing the item as evidence;
= Signature of the person that is producing the item;
= Incident/Crime reference number;
= Laboratory reference number.
CONFIRMATION COPY
The tag also contains sections for continuity purposes that can be signed when other people take custody of the item. This is used to provide continuity and assure provenance of the item from the time the item was seized to the time the item is used as evidence in court, restored to the owner, or destroyed.
The continuity sections usually show the following details:
= name/Rank and number of person taking custody of the item;
= signature of the person taking custody of the item;
= date and time the person takes custody of the item.
It is not uncommon for many bags of evidence to be seized when a crime scene is visited and the size, shape and type of those bags vary depending upon the contents and type of article.
For this reason different capacity bags are used.
This individual wrapping also permits various articles to be distributed between the various specialist laboratories that can process that item. For example some items may require fingerprint analysis, others may require DNA analysis, whilst others may just require interpretation of their contents by the investigating officer.
As computer technology has become ever more sophisticated and storage media capacities have increased, forensic capture and analysis digital evidence for investigation has become ever harder.
Currently in the digital world the closest equivalent to the physical evidence capture process is either the plain 'dd' image file (see, for example, "The Linux Kernel and the Forensic Acquisition of Hard Disks with an Odd Number of Sectors" - Jesse D. Kornblum, International Journal of Digital Evidence, Fall 2004, Volume 3, Issue 2) or one of many proprietary formats produced by various forensic tool vendors.
Traditional methods of forensic data capture involve copying a complete digital image of a digital medium (e.g. computer hard disc) as a single digital image, which must subsequently be analysed as a single entity by analysis tools.
The 'dd' raw file capture contains no method of attaching details such as the date and time of capture, the person performing the capture process, or any mechanism to help assure the integrity of what has been captured. These features can be generated after the capture but
FIELD OF THE INVENTION
The present invention relates to apparatus, methods, data structures, and programs for computers for digital evidence gathering, tracking, and analysis and systems incorporating the same.
BACKGROUND TO THE INVENTION
In the world of law enforcement when a crime scene is visited in the course of an enquiry or investigation, the law enforcement officers use bags and seals to store items of evidence that are found which are considered relevant at the time. The item would then be placed into a bag which is sealed at the scene. The seal number is recorded and a tag is attached which may include details such as:
= Investigating Agency / Police Force;
= Exhibit reference number;
= Property reference number;
= Case/Suspect name;
= Brief description of the item;
= Date and time the item was seized/produced;
= Location of where the item was seized/produced;
= Name of the person that is producing the item as evidence;
= Signature of the person that is producing the item;
= Incident/Crime reference number;
= Laboratory reference number.
CONFIRMATION COPY
The tag also contains sections for continuity purposes that can be signed when other people take custody of the item. This is used to provide continuity and assure provenance of the item from the time the item was seized to the time the item is used as evidence in court, restored to the owner, or destroyed.
The continuity sections usually show the following details:
= name/Rank and number of person taking custody of the item;
= signature of the person taking custody of the item;
= date and time the person takes custody of the item.
It is not uncommon for many bags of evidence to be seized when a crime scene is visited and the size, shape and type of those bags vary depending upon the contents and type of article.
For this reason different capacity bags are used.
This individual wrapping also permits various articles to be distributed between the various specialist laboratories that can process that item. For example some items may require fingerprint analysis, others may require DNA analysis, whilst others may just require interpretation of their contents by the investigating officer.
As computer technology has become ever more sophisticated and storage media capacities have increased, forensic capture and analysis digital evidence for investigation has become ever harder.
Currently in the digital world the closest equivalent to the physical evidence capture process is either the plain 'dd' image file (see, for example, "The Linux Kernel and the Forensic Acquisition of Hard Disks with an Odd Number of Sectors" - Jesse D. Kornblum, International Journal of Digital Evidence, Fall 2004, Volume 3, Issue 2) or one of many proprietary formats produced by various forensic tool vendors.
Traditional methods of forensic data capture involve copying a complete digital image of a digital medium (e.g. computer hard disc) as a single digital image, which must subsequently be analysed as a single entity by analysis tools.
The 'dd' raw file capture contains no method of attaching details such as the date and time of capture, the person performing the capture process, or any mechanism to help assure the integrity of what has been captured. These features can be generated after the capture but
2 usually require additional actions of the person carrying out the process as separate distinct functions.
Given that currently available electronic storage discs may have capacities of at least 250Gb - a figure which is almost certain to increase in the future - the task of processing such large units of data is becoming unmanageable.
Nevertheless, there is a legal need to ensure that base data used in analysis comprehensively and accurately reflects the contents of the system under investigation precisely at the time the digital evidence was captured. Capture of a complete digital image of the systems under investigation has therefore been deemed necessary to satisfy that requirement.
These methods generally capture the whole of the evidence into a single one size fits all data 'entity'. If the item being captured is too large to fit into one file, as it often is given the ever-increasing capacity of modern hard disk drives, then the file is fragmented into 'chunks'. This is to allow the file to be backed up later, or to be split between multiple smaller media if insufficient capacity single storage devices are not available at the time of capture.
However, in order to be able to process the contents of either of these types of data capture output, the totality of the fragmented files usually has to be made available again to the single application that is going to be used to process that evidence.
As a result, known digital evidence analysis tools are designed to operate only on these large digital dump files despite, for example, an investigator's knowledge that, for a financial irregularities investigation, analysis of only certain kinds of file (e.g.
spreadsheets and letter and memo formats) may be most appropriate and efficient whilst for a musical copyright infringement investigation analysis of music download file formats and web log files may be most appropriate. Nevertheless present evidence capture provides only a one-size-fits-all solution in the form of capture of a digital dump of the system being investigated and subsequent analysis of that complete dump as a single entity.
There is a further need to be able to provide evidence of the provenance of any digital evidence submitted as courtroom evidence: that is, evidence that the digital image submitted is indeed a faithful and complete copy of the system under analysis and that it has not been tampered with (see for example "Digital Provenance - Interpretation, Verification &
Corroboration" - Philip Turner, Digital Investigation, 2005).
Referring to Figure 1, the system described in the EnCase Legal Journal system (published by Guidance Software, December 2004 - sections 5.0-5.5) provides a system in which digital evidence 1 can be downloaded into an evidence file 10. The data may optionally be
Given that currently available electronic storage discs may have capacities of at least 250Gb - a figure which is almost certain to increase in the future - the task of processing such large units of data is becoming unmanageable.
Nevertheless, there is a legal need to ensure that base data used in analysis comprehensively and accurately reflects the contents of the system under investigation precisely at the time the digital evidence was captured. Capture of a complete digital image of the systems under investigation has therefore been deemed necessary to satisfy that requirement.
These methods generally capture the whole of the evidence into a single one size fits all data 'entity'. If the item being captured is too large to fit into one file, as it often is given the ever-increasing capacity of modern hard disk drives, then the file is fragmented into 'chunks'. This is to allow the file to be backed up later, or to be split between multiple smaller media if insufficient capacity single storage devices are not available at the time of capture.
However, in order to be able to process the contents of either of these types of data capture output, the totality of the fragmented files usually has to be made available again to the single application that is going to be used to process that evidence.
As a result, known digital evidence analysis tools are designed to operate only on these large digital dump files despite, for example, an investigator's knowledge that, for a financial irregularities investigation, analysis of only certain kinds of file (e.g.
spreadsheets and letter and memo formats) may be most appropriate and efficient whilst for a musical copyright infringement investigation analysis of music download file formats and web log files may be most appropriate. Nevertheless present evidence capture provides only a one-size-fits-all solution in the form of capture of a digital dump of the system being investigated and subsequent analysis of that complete dump as a single entity.
There is a further need to be able to provide evidence of the provenance of any digital evidence submitted as courtroom evidence: that is, evidence that the digital image submitted is indeed a faithful and complete copy of the system under analysis and that it has not been tampered with (see for example "Digital Provenance - Interpretation, Verification &
Corroboration" - Philip Turner, Digital Investigation, 2005).
Referring to Figure 1, the system described in the EnCase Legal Journal system (published by Guidance Software, December 2004 - sections 5.0-5.5) provides a system in which digital evidence 1 can be downloaded into an evidence file 10. The data may optionally be
3 compressed for space efficiency, provided that the compression algorithm preserves all the detail of the original data. CRC digits are appended to individual sectors throughout the binary dump, and stored as separate blocks 11 scattered throughout the file. These check digits provide the means of confirming that individual blocks have been neither tampered with nor accidentally corrupted. By associating them with sub-blocks of the entire binary dump it also mitigates the evidential impact of such corruption, from whichever cause, thereby allowing other uncorrupted blocks from the same file potentially to continue to be admitted as evidence. An MD5 hash 121 of the whole binary image is also stored in a footer component 12 of the evidence file so as to provide further data integrity checks to protect against corruption or tampering.
To provide provenance (or "chain of custody") information, each EnCase Evidence file also comprises a header section 13 containing custody information: for example the identity of the examined computer, date and time of evidence image capture, identity of investigator making the image, etc, along with an MD5 hash value for the captured data at the time of acquisition.
This provenance information cannot however be modified from within the EnCase software, and therefore cannot be used to track subsequent changes of custody or analyses performed upon the evidence file. The provenance information is designed solely to represent provenance at the moment of data capture.
Furthermore, since the Encase system embeds data other than that from the original source (e.g. header 13, footer 12, and CRC check digits 11) within the evidence files 10, it is in general impractical to apply other COTS analysis tools to those evidential files since they are not designed to take account of such proprietary file structurings. Instead it is recommended that investigators first restore a physical device from the EnCase image and then apply the other analysis tools to that image. This process is potentially highly time consuming and also, by extracting the image data from within the Evidence file, potentially breaks the provenance chain from the original.
The paper "Breaking the Performance Wall: The Case for Distributed Digital Forensics" (Vassil Roussev, Golden G. Richard III, Department of Computer Science, University of New Orleans, LA70148) discusses distribution of analyses of digital evidence.
Patent application US 2004/0260733 Al discloses techniques for allowing a user to remotely interrogate a target computing device in order to collect and analyze computer evidence which may be stored on the target computing device.
To provide provenance (or "chain of custody") information, each EnCase Evidence file also comprises a header section 13 containing custody information: for example the identity of the examined computer, date and time of evidence image capture, identity of investigator making the image, etc, along with an MD5 hash value for the captured data at the time of acquisition.
This provenance information cannot however be modified from within the EnCase software, and therefore cannot be used to track subsequent changes of custody or analyses performed upon the evidence file. The provenance information is designed solely to represent provenance at the moment of data capture.
Furthermore, since the Encase system embeds data other than that from the original source (e.g. header 13, footer 12, and CRC check digits 11) within the evidence files 10, it is in general impractical to apply other COTS analysis tools to those evidential files since they are not designed to take account of such proprietary file structurings. Instead it is recommended that investigators first restore a physical device from the EnCase image and then apply the other analysis tools to that image. This process is potentially highly time consuming and also, by extracting the image data from within the Evidence file, potentially breaks the provenance chain from the original.
The paper "Breaking the Performance Wall: The Case for Distributed Digital Forensics" (Vassil Roussev, Golden G. Richard III, Department of Computer Science, University of New Orleans, LA70148) discusses distribution of analyses of digital evidence.
Patent application US 2004/0260733 Al discloses techniques for allowing a user to remotely interrogate a target computing device in order to collect and analyze computer evidence which may be stored on the target computing device.
4 Patent application EP 0 893 763 Al discloses systems for verifying and authenticating the integrity of data copied from computer memories. It employs hash values calculated over individual blocks of copied data, the hash values being encrypted and stored on external media (e.g. floppy disk).
SUMMARY OF THE INVENTION
According to a first aspect of the present invention, there is provided a method of capturing digital data, the method comprising the steps of: copying digital data from a data source into one or more evidence files; for each evidence file recording data descriptive of at least one of the source and the contents of the digital data in the evidence file;
recording, in a tag file, data indicative of provenance of the digital data in the one or more evidence files.
The digital data may be copied into a plurality of evidence files.
The digital data may be selectively copied from the source (i.e. not all the data from the given source need be copied into any given evidence file.) For each evidence file, the data descriptive of one of the source and contents of the digital data may be stored in an index file distinct from the evidence file.
A distinct index file may be created for each evidence file.
The data descriptive of one of the source and contents of the digital data may comprise a digital fingerprint of the digital data.
The tag file may comprise a digital fingerprint of at least one of the evidence files.
The tag file may comprise a description of the format of the data descriptive of one of the source and contents of the digital data.
The data source may be a data storage medium (or other static data medium) The data source may be a data transmission medium (or other dynamic data medium).
In some embodiments multiple indications of provenance are associated with at least one given item of the digital data in the one or more evidence files.
According to a second aspect of the present invention there is provided a program for a computer having respective code portions and data structures to perform the steps of the methods of other aspects of the invention.
According to a third aspect of the present invention there is provided apparatus for capturing digital data, the apparatus comprising: means for copying digital data from a data source into one or more evidence files; for each evidence file, means for recording data descriptive of at least one of the source and the contents of the digital data in the evidence file; means arranged to record, in a tag file, data indicative of provenance of the digital data in the one or more evidence files.
According to a fourth aspect of the present invention there is provided a data structure for capturing digital data, the data structure comprising: at least one evidence file for containing digital data copied from a data source; at least one index file containing data descriptive of at least one of the source and contents of the digital data in the at least one evidence files; a tag file containing data indicative of provenance of the digital data in the at least one evidence files.
According to a fifth aspect of the present invention there is provided a method of accessing a data structure according to the fourth aspect, the method comprising the steps of: identifying one or more evidence files to be accessed; recording details of the evidence file access in the tag file of the data structure; recording a new integrity check value in the tag file, responsive to the contents of the tag file including the newly-recorded details of the evidence file access.
The details of the evidence file access may comprise at least one of:
identification of the application performing the evidence file access; identification of the user requesting evidence file access; identification of the time of evidence file access;
The integrity check may be a digital fingerprint, for example one of a CRC
digits, an MD5 hash, and a SHA hash.
According to a sixth aspect of the present invention there is provided apparatus for accessing a data structure according to the fourth aspect, the apparatus comprising: means for identifying one or more evidence files to be accessed; means for recording details of the evidence file access in the tag file of the data structure; means for recording a new integrity check value in the tag file, responsive to the contents of the tag file including the newly-recorded details of the evidence file access.
According to a seventh aspect of the present invention there is provided a method of updating a data structure according to the fourth aspect, the method comprising the steps of: accessing the :data structure to extract evidential data contained within it; processing evidential data extracted from the data structure to create a new evidence file and corresponding index file;
adding the new evidence file and index file to the existing data structure;
appending continuity information to the tag file of the data structure indicative of the addition of the new evidence file and index file.
According to a eight aspect of the present invention there is provided apparatus for updating a data structure according to the fourth aspect, the apparatus comprising: means for accessing the data structure to extract evidential data contained within it; means for processing evidential data extracted from the data structure to create a new evidence file and corresponding index file; means for adding the new evidence file and index file to the existing data structure; means for appending continuity information to the tag file of the data structure indicative of the addition of the new evidence file and index file.
Advantageously, use of a common format for capturing digital data/evidence of disparate types and sizes facilitates tracking of provenance of such digital evidence whilst also facilitating efficient and selective analysis of the data by disparate analysis methods and tools. Such analysis may also be conducted concurrently on copies of the evidential data whose provenance from the original data can be tracked and verified.
The invention also provides for systems for the purposes of digital data/evidence capture and analysis which comprise one or more instances of apparatus embodying the present invention, together with other additional apparatus.
The invention also provides for computer software in a machine-readable form and arranged, in operation, to carry out every function of the apparatus and/or methods.
The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
In order to show how the invention may be carried into effect, embodiments of the invention are now described below by wayof example only and with reference to the accompanying figures in which:
Figure 1 shows a schematic diagram of a prior art digital evidence data structure;
Figure 2 shows a schematic diagram of a digital evidence data structure in accordance with the present invention;
Figure 3 shows a schematic diagram of a tag file update method according to the present invention; and Figure 4 shows an example of a tag file in accordance with the present invention.
DETAILED DESCRIPTION OF INVENTION
Referring now to Figure 2 a Digital Evidence Bag (DEB) 20 is a structured wrapper for any type of digitally based evidence or information. A DEB may have arbitrarily large capacity, subject of course to the physical limits of the storage media available to carry it.
Depending upon the user requirements a DEB may store information that could be captured either in a static environment (for example an image of a magnetic or optical storage medium) or in a real-time environment (for example a record of digital traffic over a communications medium).
A DEB comprises a tag file 21 and one or more evidence units (EU) 22a, 22b.
Each evidence unit in turn comprises index information 221 and a unit of digital evidence 222. Whilst the index information and the digital evidence itself are preferably contained in separate files (an index file and an evidence file) as illustrated, the index information could alternatively be stored in the same file as the digital evidence, for example as a recognisable file header.
Furthermore, each evidence file contains its own tag information complete with integrity assurance information.
Such DEB's allow digital information of almost any size and from any source to be stored in a forensically sound manner. Furthermore the model allows evidence stored in DEB's to be distributed to different applications which may also perform different tasks upon the contents of those evidence files. This approach also allows application independence, and permits applications which perform the same task - albeit in a different manner (e.g alternate keyword search algorithms) - to work on the same evidence, potentially concurrently.
The tag file 21 is preferably a plain text file, though it is possible that other more complex file formats may be employed (for example Microsoft Word format). The tag file contains descriptive details of the evidence units contained within the DEB of which it forms part. The information contained in the tag file is analogous to that which might be found on a physical tag attached to physical evidence when it is seized, and may for example comprise one or more of the following, or similar, items:
= an investigation identifier;
= an evidence identifier or reference;
= identification of the individual capturing the information;
= a date and time when the capture process occurred;
= a textual description of the contents of the DEB;
= continuity information.
In the digital environment however there is more scope to record information about the evidence and maintain its integrity than there is in the physical world. The tag file may therefore also be used to record the provenance of information in the DEB and to provide a continuity record of the information contained within the DEB. The tag file in a DEB can also be used to record when a DEB analysis application accesses the DEB and also to record which analyses have been performed on any EU in the DEB.
Referring now to Figures 3 and 4, the tag file 21 a may also comprise:
= a count 45 of the number of EU's in the DEB;
= integrity checks 42, 44 (e.g. CRC digits or hash) of the captured evidential data in the evidence files; and = integrity checks 41, 43 (e.g. CRC digits or hash) of the or each index file;
and = a tag seal integrity check (e.g. hash number) 31 comprising a hash of the tag file to date.
The tag file 21 a may also comprise one or more Tag Continuity Blocks (TCB) 32. A TCB is appended (or otherwise added) to the tag file 21 b each time an application performs a function on the DEB as a whole or performs a function on one or more EU's within the DEB. The TCB's may capture some or all of the following or similar DEB access data: the date andtime 46, version 47 , application ID 47, application signature (hash) 49, and function 50 of the application that has been applied to the DEB or EU. As each new TCB is appended to the tag file, a new tag seal hash number 321 is also appended, calculated over the updated contents of the tag file 21 b including the preceding contents of the newly-appended TCB
32 and any previously recorded tag seal hash numbers 31 previously present in the tag file.
An important component which affords the DEB the flexibility to hold information captured from a variety of sources (i.e. static, real-time, or selective data) is the Meta Tag structure 51 used within the DEB header. In certain circumstances it may be advantageous to compress or encrypt the contents of either a whole DEB or part (EU). This is reflected in the index file by recording an encrypted or compressed content format type.
In order to define the contents and format of the content of the index the structure is defined in the tag file. The structure definition comprises a series of Meta Tags (MT).
The MTs are used to define both sequence of fields and content type of the index. The index in turn holds information relating to the contents of the bag. Examples of Meta tag definitions include, but are not limited to:
<F> = Filename <Fx> = Filename extension/type <Fa> = File Attributes (E.g. System, Read, Archive, Hidden) <Fmft> = MFT Index number <FIs> = Logical File Size in bytes <Fps> = Physical File Size occupied <P> = Filepath / Provenential Information <Ds> = Data source (PDA) - RAM, ROM, Database (User Data), SIM, Handset <Hmd5> = Hash MD5 <Hsha> = Hash SHA
<Tmod> = Timestamp - modified <Tacc> = Timestamp - accessed <Tcre> = Timestamp - created <Temo> = Timestamp Entry modified (NTFS) <Tpacket> = Packet time <Ddes> = Device Descriptor <Dman> = Device Manufacturer <Dmod> = Device model <Dsn> = Device Serial Number <Dcap> = Device capacity <Dpin> = Device PIN, security access code, password <Dsp> = Device service provider (phone) <Raw> = Bag contents are RAW/binary no structure Where particular index file formats become, for example, common or standard abbreviations may of course be introduced for brevity. For example an abbreviation:
<FAT12>
may be used to denote the meta tag sequence:
<F> <Fx> <Fa> <FIs> <Fps> ... etc.
Although only a single index format 51 applicable to all EU's within the DEB
is illustrated in Figure 4, clearly the index format details may be defined on a per-index file basis.
Each index file is a tab-delimited plain text file (though other formats may be used), containing a list detailing the contents of the corresponding evidence file. The index file may contain details such as a list of filenames, folder paths, and timestamp information relating to the contents of the digital information in the corresponding evidence file. It may contain details of a physical device from which the evidence was extracted, for example the make, model, and serial number of the device captured. The exact format and structure of the index file is reflected in the tag information in the tag file 21. The tag information therefore provides to analysis tools an indication of the structure within the various evidence units since, unlike known systems, the individual evidence units may exhibit different structure.
The evidence files contain the actual evidential data/information itself. The contents of these evidence files may be, but is not limited to, raw binary information (e.g.
from a raw device capture as in known systems), files (e.g. from logical volume acquisition), structured binary information (e.g. from network protocol packet capture), or categorized files (e.g. one evidence file containing all text files, another containing all Microsoft Word documents, or another containing all JPEG graphics files, etc.).
Creating one evidence file per evidence source file acquired (e.g. one JPEG
file into one evidence file) is also an option. Whilst this may lead to very large tag files, it may be appropriate where individual files may be of particular evidential interest.
DEB application programs may be provided which update the tag file so that its contents reflect the history of operations performed on the evidence files. Such information would include the date and time the application was applied to the evidence unit, include an application signature so that it is known what category of application and what version of application was used. The DEB application should also update the tag seal number.
To support the DEB model, applications which can create and use DEB's can be described in number of categories:
= DEB capture applications: These are used to create the DEB from any type of digital source whether it be static disk capture, PDA capture, mobile telephone capture or live network packet capture to name but a few. The importance of this is that all these various digital processes can store evidence in a common data structure in the form of a DEB, as described above.
= DEB analysis applications - These are used to perform an operation on an already created DEB. The type of operations that may be undertaken include, but are not limited to, keyword searches, hash analysis, graphical image analysis and characterisation, password cracking, log file analysis etc. When an operation is undertaken on the contents of a DEB, a log may be kept in the tag file of the function that was performed on the evidence. This provides an audit trail of the date, time, type of task, version of DEB analysis application that was used.
If information from disparate digital sources is encapsulated into DEB's and processed using the DEB analysis application then this would significantly streamline the processing of digitally based evidence. It also allows tool vendors to create applications which can operate on a self-contained DEB and allow investigators to obtain tools that perform specific operations on EU's.
This would allow analysis applications to be provided by different vendors to work on the same evidence, without requiring the investigator to translate the format in which that information was acquired, into another format, just to run against another tool. This will have the effect of reducing time in conversion and the storage capacity required to hold the various versions of what is ultimately exactly the same information, but stored with different headers, or in an uncompressed format.
Because of the flexibility that DEB's bring to the world of digital forensics, the current dumb approach to image capture (i.e. start from the beginning of the media and capture everything until the end) can be replaced with imagers that operate in a more intelligent or selective manner. For example an imager could capture all files of one particular type to one DEB and another type to another DEB. Similarly the imager could be more 'intelligent' and target specific information for example a forensic triage could be carried out just capturing system configuration information thus allowing the investigator the opportunity to discover the operating capability that a system possessed. Alternatively if the focus of an investigation was very narrow, for example to determine if a system contained indecent images then an imager could capture specific types of files to a DEB.
It is also noted that DEB format and structure is such that it can be used with existing applications run from a 'wrapper' application. This permits existing applications to be used immediately with no, or minimal, modification but with the additional benefits of information assurance, integrity and continuity provided by the DEB data structure and methods.
The ability of a DEB or EU to hold entirely one type of information allows the whole digital case to be divided between systems, applications or process that can handle that category of information. Extending this further allows DEB's or EU's to be distributed across a range of systems in a multitasking and or multiprocessing environment to applications that are best suited to deal with that category of information. This would allow a forensic controller the ability to distribute DEB's or EU's to worker (client) applications safe in the knowledge that those workers would update the DEB continuity information showing what process or function was carried out on that evidence.
As a DEB or EU is passed to different analysis applications, the continuity information on the seal is updated. Thus it provides a log of the tasks and processes performed on that evidence.
Another feature of the DEB concept is the ability to maintain continuity information and to be able to show the provenance of the information contained within the DEB.
Coupled with this is the requirement to both maintain and assure the integrity of the evidence within the DEB.
A practical approach to introducing and utilizing DEBs is to employ an extensible format definition which can develop over time and may therefore be enhanced to meet future requirements. Thus early implementations of the DEB approach might use it as a'wrapper' for current forensic tools and applications. This has an immediate benefit that experience can be gained in using and applying DEB format with the tools that are commonly used and accepted today.
There is no manual on how to be an investigator, and passing on the knowledge of what makes a good investigative practice is very difficult and time consuming. In the digital world just keeping up with the current technological advances is almost impossible.
However, the DEB
approach of logging which applications and processes are carried out on the evidence, along potentially with the sequence in which those analysis tasks are performed in an automated process, enhances investigators' ability to learn the most effective order to undertake tasks.
Furthermore, this type of mechanism could also assist in the testing and certification of investigators, as it would permit trainees to undertake test cases and record how investigators tackled them.
The following advantages are immediately evident from the data structures and methods described:
= Scaleable approach to evidence acquisition;
= Scalable approach to forensic processing, allowing for the first time the digital evidence to be processed across multi-processor and distributed systems;
= Increased evidential material throughput, directing the most applicable techniques to the appropriate types of evidence;
= Incorporate some of the current evidence capture and analysis methods thus not negating the financial investment in current tools and methods;
= The ability to process evidence from a diverse range of digital devices;
= Allow the integration of real-time data acquisition into a sound forensic framework;
= Permit a selective and/or intelligent data acquisition approach to be implemented as opposed to the current collect everything approach;
= The ability to automatically create an audit trail of processes carried out on a piece of evidence, the metric from which could allow analysis of the most effective way to process digital evidence and be used to educate new practitioners in the best way to undertake a forensic investigation.
Although described predominantly in the context of digital evidence gathering, the present inventions not limited to such applications but may also be applied in other situations in which provenance and continuity of captured data is important, as would be apparent to the person skilled in the art.
Partial or selective data copying may be considered as an alternative to capturing the whole image when it may not be practical to acquire everything. Such partial copying is know as "selective imaging". One reason for applying a selective approach is the quantity of information that may have to be acquired. Other reasons for performing a selective acquisition may include but are not limited to forensic triage, intelligence gathering, and legal requirements. There may be legal reasons why a selective approach should be adopted, for example a case involving Legal Professional Privilege (LPP) material. Adopting a selective approach has cerain risks associated with it, but this in no way means the evidence should not be gathered in any less scientific or rigorous manner.
There are several types of selective imaging techniques that may be used.
These include manual selective imaging, semi-automatic selective imaging, and automatic selective imaging.
Manual Selective Imaging is where a forensic investigator chooses exactly which files are captured. For example, the investigator can use an interface similar to that of a file browser and is able to navigate the directory tree and choose which files to acquire.
Semi-automatic selective imaging is where a forensic investigator decides which file types or categories of information to capture. This may be based on file extension, file signature, or file hash, or some other definable criteria. When using a selective approach based on file hashes it is important to record which files are present and their provenance, even though the contents of each file may not be captured. It is also be prudent to record referential hash set information.
Automatic selective imaging is where an investigator selects the source and destination devices and the imager automatically acquires the evidence. This is accomplished in a selective manner according to pre-configured parameters or the particular circumstances pertaining to the case / investigation.
The different operating modes that a selective approach presents to the investigator, combined with the flexibility and many options for classifying and grouping information, potentially makes the task very complex. One of the difficulties with selective imaging is recording the provenance of each item selected. This provides a number of options and there is often more than one metric that can be used to record the provenance of an item of information. For example, the location of a particular file on a disk could be recorded in any or all of the following ways:
= physical sector locations (data runs);
= logical cluster locations within a volume, with the addition of an offset from the beginning of the physical device;
= folder location specified from the root folder. This must include partition reference information.
It is not in general possible to categorise any one of these forms as inherently better than any other; none signifies that the evidence associated with it is in ay way inherently 'better' or has more integrity than that associated with any other method.
Provenance indications are preferably unique, unambiguous, concise, and repeatable. Each method meets these criteria in different ways, dependent upon the technical knowledge of the person trying to understand it. For example the general public, a judge, or a legal professional is likely to be more familiar with the concept of a folder location than a more technical concept such as absolute location or cluster reference. These other 'more technical' provenance descriptions may only complicate matters by introducing more technical vocabulary which in practice detracts from and obscures the real information that is to be presented. In an ideal world all relevant provenential descriptions would be captured though in practice this may not be practical. Nevertheless it is considered desirable to be able to capture multiple indications of provenance associated with any given evidence, rather than be restricted to capturing only one in each case.
This would lead to multiple provenential definitions, for example:
= Primary Provenential Key = Physical sector locations;
= Secondary Provenential Key = Logical cluster locations within a volume with the addition of an offset from the beginning of the physical device;
= Tertiary Provenential Key = Folder location specified from the root folder.
It is also possible to have a DEB containing one or more other DEBs: that is, the content type of a DEB may also itself be a DEB. This ability to encapsulate DEBs within DEBs permits a parallel approach to be taken to the acquisition process, thus combining the acquired evidence into one entity for analysis. One example of this would be the simultaneous acquisition of data from distinct disks making up a RAID set: each disk may be captured, potentially concurrently, in a separate DEB and these DEBs in turn encapsulated in a further DEB. Other examples in which data may be concurrently or hierarchically gathered into DEBs will be apparent to the skilled person.
DEBs also support the duplication of either all or selected information from a given source DEB
whereby to create another DEB, together with an audit trail showing the provenance of the copied information. The audit trail may be shown both in the tag field of the originating DEB
from which the new DEB is created and in the tag field of the new DEB itself.
The original DEB
will contain an indication that an application has extracted certain information, whilst the new DEB will contain an indication of where the information contained in it came from.
DEBs may of course be stored on or transmitted via any form of digital medium including, but not limited to, optical, magnetic and wireless media .
Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person for an understanding of the teachings herein.
SUMMARY OF THE INVENTION
According to a first aspect of the present invention, there is provided a method of capturing digital data, the method comprising the steps of: copying digital data from a data source into one or more evidence files; for each evidence file recording data descriptive of at least one of the source and the contents of the digital data in the evidence file;
recording, in a tag file, data indicative of provenance of the digital data in the one or more evidence files.
The digital data may be copied into a plurality of evidence files.
The digital data may be selectively copied from the source (i.e. not all the data from the given source need be copied into any given evidence file.) For each evidence file, the data descriptive of one of the source and contents of the digital data may be stored in an index file distinct from the evidence file.
A distinct index file may be created for each evidence file.
The data descriptive of one of the source and contents of the digital data may comprise a digital fingerprint of the digital data.
The tag file may comprise a digital fingerprint of at least one of the evidence files.
The tag file may comprise a description of the format of the data descriptive of one of the source and contents of the digital data.
The data source may be a data storage medium (or other static data medium) The data source may be a data transmission medium (or other dynamic data medium).
In some embodiments multiple indications of provenance are associated with at least one given item of the digital data in the one or more evidence files.
According to a second aspect of the present invention there is provided a program for a computer having respective code portions and data structures to perform the steps of the methods of other aspects of the invention.
According to a third aspect of the present invention there is provided apparatus for capturing digital data, the apparatus comprising: means for copying digital data from a data source into one or more evidence files; for each evidence file, means for recording data descriptive of at least one of the source and the contents of the digital data in the evidence file; means arranged to record, in a tag file, data indicative of provenance of the digital data in the one or more evidence files.
According to a fourth aspect of the present invention there is provided a data structure for capturing digital data, the data structure comprising: at least one evidence file for containing digital data copied from a data source; at least one index file containing data descriptive of at least one of the source and contents of the digital data in the at least one evidence files; a tag file containing data indicative of provenance of the digital data in the at least one evidence files.
According to a fifth aspect of the present invention there is provided a method of accessing a data structure according to the fourth aspect, the method comprising the steps of: identifying one or more evidence files to be accessed; recording details of the evidence file access in the tag file of the data structure; recording a new integrity check value in the tag file, responsive to the contents of the tag file including the newly-recorded details of the evidence file access.
The details of the evidence file access may comprise at least one of:
identification of the application performing the evidence file access; identification of the user requesting evidence file access; identification of the time of evidence file access;
The integrity check may be a digital fingerprint, for example one of a CRC
digits, an MD5 hash, and a SHA hash.
According to a sixth aspect of the present invention there is provided apparatus for accessing a data structure according to the fourth aspect, the apparatus comprising: means for identifying one or more evidence files to be accessed; means for recording details of the evidence file access in the tag file of the data structure; means for recording a new integrity check value in the tag file, responsive to the contents of the tag file including the newly-recorded details of the evidence file access.
According to a seventh aspect of the present invention there is provided a method of updating a data structure according to the fourth aspect, the method comprising the steps of: accessing the :data structure to extract evidential data contained within it; processing evidential data extracted from the data structure to create a new evidence file and corresponding index file;
adding the new evidence file and index file to the existing data structure;
appending continuity information to the tag file of the data structure indicative of the addition of the new evidence file and index file.
According to a eight aspect of the present invention there is provided apparatus for updating a data structure according to the fourth aspect, the apparatus comprising: means for accessing the data structure to extract evidential data contained within it; means for processing evidential data extracted from the data structure to create a new evidence file and corresponding index file; means for adding the new evidence file and index file to the existing data structure; means for appending continuity information to the tag file of the data structure indicative of the addition of the new evidence file and index file.
Advantageously, use of a common format for capturing digital data/evidence of disparate types and sizes facilitates tracking of provenance of such digital evidence whilst also facilitating efficient and selective analysis of the data by disparate analysis methods and tools. Such analysis may also be conducted concurrently on copies of the evidential data whose provenance from the original data can be tracked and verified.
The invention also provides for systems for the purposes of digital data/evidence capture and analysis which comprise one or more instances of apparatus embodying the present invention, together with other additional apparatus.
The invention also provides for computer software in a machine-readable form and arranged, in operation, to carry out every function of the apparatus and/or methods.
The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
In order to show how the invention may be carried into effect, embodiments of the invention are now described below by wayof example only and with reference to the accompanying figures in which:
Figure 1 shows a schematic diagram of a prior art digital evidence data structure;
Figure 2 shows a schematic diagram of a digital evidence data structure in accordance with the present invention;
Figure 3 shows a schematic diagram of a tag file update method according to the present invention; and Figure 4 shows an example of a tag file in accordance with the present invention.
DETAILED DESCRIPTION OF INVENTION
Referring now to Figure 2 a Digital Evidence Bag (DEB) 20 is a structured wrapper for any type of digitally based evidence or information. A DEB may have arbitrarily large capacity, subject of course to the physical limits of the storage media available to carry it.
Depending upon the user requirements a DEB may store information that could be captured either in a static environment (for example an image of a magnetic or optical storage medium) or in a real-time environment (for example a record of digital traffic over a communications medium).
A DEB comprises a tag file 21 and one or more evidence units (EU) 22a, 22b.
Each evidence unit in turn comprises index information 221 and a unit of digital evidence 222. Whilst the index information and the digital evidence itself are preferably contained in separate files (an index file and an evidence file) as illustrated, the index information could alternatively be stored in the same file as the digital evidence, for example as a recognisable file header.
Furthermore, each evidence file contains its own tag information complete with integrity assurance information.
Such DEB's allow digital information of almost any size and from any source to be stored in a forensically sound manner. Furthermore the model allows evidence stored in DEB's to be distributed to different applications which may also perform different tasks upon the contents of those evidence files. This approach also allows application independence, and permits applications which perform the same task - albeit in a different manner (e.g alternate keyword search algorithms) - to work on the same evidence, potentially concurrently.
The tag file 21 is preferably a plain text file, though it is possible that other more complex file formats may be employed (for example Microsoft Word format). The tag file contains descriptive details of the evidence units contained within the DEB of which it forms part. The information contained in the tag file is analogous to that which might be found on a physical tag attached to physical evidence when it is seized, and may for example comprise one or more of the following, or similar, items:
= an investigation identifier;
= an evidence identifier or reference;
= identification of the individual capturing the information;
= a date and time when the capture process occurred;
= a textual description of the contents of the DEB;
= continuity information.
In the digital environment however there is more scope to record information about the evidence and maintain its integrity than there is in the physical world. The tag file may therefore also be used to record the provenance of information in the DEB and to provide a continuity record of the information contained within the DEB. The tag file in a DEB can also be used to record when a DEB analysis application accesses the DEB and also to record which analyses have been performed on any EU in the DEB.
Referring now to Figures 3 and 4, the tag file 21 a may also comprise:
= a count 45 of the number of EU's in the DEB;
= integrity checks 42, 44 (e.g. CRC digits or hash) of the captured evidential data in the evidence files; and = integrity checks 41, 43 (e.g. CRC digits or hash) of the or each index file;
and = a tag seal integrity check (e.g. hash number) 31 comprising a hash of the tag file to date.
The tag file 21 a may also comprise one or more Tag Continuity Blocks (TCB) 32. A TCB is appended (or otherwise added) to the tag file 21 b each time an application performs a function on the DEB as a whole or performs a function on one or more EU's within the DEB. The TCB's may capture some or all of the following or similar DEB access data: the date andtime 46, version 47 , application ID 47, application signature (hash) 49, and function 50 of the application that has been applied to the DEB or EU. As each new TCB is appended to the tag file, a new tag seal hash number 321 is also appended, calculated over the updated contents of the tag file 21 b including the preceding contents of the newly-appended TCB
32 and any previously recorded tag seal hash numbers 31 previously present in the tag file.
An important component which affords the DEB the flexibility to hold information captured from a variety of sources (i.e. static, real-time, or selective data) is the Meta Tag structure 51 used within the DEB header. In certain circumstances it may be advantageous to compress or encrypt the contents of either a whole DEB or part (EU). This is reflected in the index file by recording an encrypted or compressed content format type.
In order to define the contents and format of the content of the index the structure is defined in the tag file. The structure definition comprises a series of Meta Tags (MT).
The MTs are used to define both sequence of fields and content type of the index. The index in turn holds information relating to the contents of the bag. Examples of Meta tag definitions include, but are not limited to:
<F> = Filename <Fx> = Filename extension/type <Fa> = File Attributes (E.g. System, Read, Archive, Hidden) <Fmft> = MFT Index number <FIs> = Logical File Size in bytes <Fps> = Physical File Size occupied <P> = Filepath / Provenential Information <Ds> = Data source (PDA) - RAM, ROM, Database (User Data), SIM, Handset <Hmd5> = Hash MD5 <Hsha> = Hash SHA
<Tmod> = Timestamp - modified <Tacc> = Timestamp - accessed <Tcre> = Timestamp - created <Temo> = Timestamp Entry modified (NTFS) <Tpacket> = Packet time <Ddes> = Device Descriptor <Dman> = Device Manufacturer <Dmod> = Device model <Dsn> = Device Serial Number <Dcap> = Device capacity <Dpin> = Device PIN, security access code, password <Dsp> = Device service provider (phone) <Raw> = Bag contents are RAW/binary no structure Where particular index file formats become, for example, common or standard abbreviations may of course be introduced for brevity. For example an abbreviation:
<FAT12>
may be used to denote the meta tag sequence:
<F> <Fx> <Fa> <FIs> <Fps> ... etc.
Although only a single index format 51 applicable to all EU's within the DEB
is illustrated in Figure 4, clearly the index format details may be defined on a per-index file basis.
Each index file is a tab-delimited plain text file (though other formats may be used), containing a list detailing the contents of the corresponding evidence file. The index file may contain details such as a list of filenames, folder paths, and timestamp information relating to the contents of the digital information in the corresponding evidence file. It may contain details of a physical device from which the evidence was extracted, for example the make, model, and serial number of the device captured. The exact format and structure of the index file is reflected in the tag information in the tag file 21. The tag information therefore provides to analysis tools an indication of the structure within the various evidence units since, unlike known systems, the individual evidence units may exhibit different structure.
The evidence files contain the actual evidential data/information itself. The contents of these evidence files may be, but is not limited to, raw binary information (e.g.
from a raw device capture as in known systems), files (e.g. from logical volume acquisition), structured binary information (e.g. from network protocol packet capture), or categorized files (e.g. one evidence file containing all text files, another containing all Microsoft Word documents, or another containing all JPEG graphics files, etc.).
Creating one evidence file per evidence source file acquired (e.g. one JPEG
file into one evidence file) is also an option. Whilst this may lead to very large tag files, it may be appropriate where individual files may be of particular evidential interest.
DEB application programs may be provided which update the tag file so that its contents reflect the history of operations performed on the evidence files. Such information would include the date and time the application was applied to the evidence unit, include an application signature so that it is known what category of application and what version of application was used. The DEB application should also update the tag seal number.
To support the DEB model, applications which can create and use DEB's can be described in number of categories:
= DEB capture applications: These are used to create the DEB from any type of digital source whether it be static disk capture, PDA capture, mobile telephone capture or live network packet capture to name but a few. The importance of this is that all these various digital processes can store evidence in a common data structure in the form of a DEB, as described above.
= DEB analysis applications - These are used to perform an operation on an already created DEB. The type of operations that may be undertaken include, but are not limited to, keyword searches, hash analysis, graphical image analysis and characterisation, password cracking, log file analysis etc. When an operation is undertaken on the contents of a DEB, a log may be kept in the tag file of the function that was performed on the evidence. This provides an audit trail of the date, time, type of task, version of DEB analysis application that was used.
If information from disparate digital sources is encapsulated into DEB's and processed using the DEB analysis application then this would significantly streamline the processing of digitally based evidence. It also allows tool vendors to create applications which can operate on a self-contained DEB and allow investigators to obtain tools that perform specific operations on EU's.
This would allow analysis applications to be provided by different vendors to work on the same evidence, without requiring the investigator to translate the format in which that information was acquired, into another format, just to run against another tool. This will have the effect of reducing time in conversion and the storage capacity required to hold the various versions of what is ultimately exactly the same information, but stored with different headers, or in an uncompressed format.
Because of the flexibility that DEB's bring to the world of digital forensics, the current dumb approach to image capture (i.e. start from the beginning of the media and capture everything until the end) can be replaced with imagers that operate in a more intelligent or selective manner. For example an imager could capture all files of one particular type to one DEB and another type to another DEB. Similarly the imager could be more 'intelligent' and target specific information for example a forensic triage could be carried out just capturing system configuration information thus allowing the investigator the opportunity to discover the operating capability that a system possessed. Alternatively if the focus of an investigation was very narrow, for example to determine if a system contained indecent images then an imager could capture specific types of files to a DEB.
It is also noted that DEB format and structure is such that it can be used with existing applications run from a 'wrapper' application. This permits existing applications to be used immediately with no, or minimal, modification but with the additional benefits of information assurance, integrity and continuity provided by the DEB data structure and methods.
The ability of a DEB or EU to hold entirely one type of information allows the whole digital case to be divided between systems, applications or process that can handle that category of information. Extending this further allows DEB's or EU's to be distributed across a range of systems in a multitasking and or multiprocessing environment to applications that are best suited to deal with that category of information. This would allow a forensic controller the ability to distribute DEB's or EU's to worker (client) applications safe in the knowledge that those workers would update the DEB continuity information showing what process or function was carried out on that evidence.
As a DEB or EU is passed to different analysis applications, the continuity information on the seal is updated. Thus it provides a log of the tasks and processes performed on that evidence.
Another feature of the DEB concept is the ability to maintain continuity information and to be able to show the provenance of the information contained within the DEB.
Coupled with this is the requirement to both maintain and assure the integrity of the evidence within the DEB.
A practical approach to introducing and utilizing DEBs is to employ an extensible format definition which can develop over time and may therefore be enhanced to meet future requirements. Thus early implementations of the DEB approach might use it as a'wrapper' for current forensic tools and applications. This has an immediate benefit that experience can be gained in using and applying DEB format with the tools that are commonly used and accepted today.
There is no manual on how to be an investigator, and passing on the knowledge of what makes a good investigative practice is very difficult and time consuming. In the digital world just keeping up with the current technological advances is almost impossible.
However, the DEB
approach of logging which applications and processes are carried out on the evidence, along potentially with the sequence in which those analysis tasks are performed in an automated process, enhances investigators' ability to learn the most effective order to undertake tasks.
Furthermore, this type of mechanism could also assist in the testing and certification of investigators, as it would permit trainees to undertake test cases and record how investigators tackled them.
The following advantages are immediately evident from the data structures and methods described:
= Scaleable approach to evidence acquisition;
= Scalable approach to forensic processing, allowing for the first time the digital evidence to be processed across multi-processor and distributed systems;
= Increased evidential material throughput, directing the most applicable techniques to the appropriate types of evidence;
= Incorporate some of the current evidence capture and analysis methods thus not negating the financial investment in current tools and methods;
= The ability to process evidence from a diverse range of digital devices;
= Allow the integration of real-time data acquisition into a sound forensic framework;
= Permit a selective and/or intelligent data acquisition approach to be implemented as opposed to the current collect everything approach;
= The ability to automatically create an audit trail of processes carried out on a piece of evidence, the metric from which could allow analysis of the most effective way to process digital evidence and be used to educate new practitioners in the best way to undertake a forensic investigation.
Although described predominantly in the context of digital evidence gathering, the present inventions not limited to such applications but may also be applied in other situations in which provenance and continuity of captured data is important, as would be apparent to the person skilled in the art.
Partial or selective data copying may be considered as an alternative to capturing the whole image when it may not be practical to acquire everything. Such partial copying is know as "selective imaging". One reason for applying a selective approach is the quantity of information that may have to be acquired. Other reasons for performing a selective acquisition may include but are not limited to forensic triage, intelligence gathering, and legal requirements. There may be legal reasons why a selective approach should be adopted, for example a case involving Legal Professional Privilege (LPP) material. Adopting a selective approach has cerain risks associated with it, but this in no way means the evidence should not be gathered in any less scientific or rigorous manner.
There are several types of selective imaging techniques that may be used.
These include manual selective imaging, semi-automatic selective imaging, and automatic selective imaging.
Manual Selective Imaging is where a forensic investigator chooses exactly which files are captured. For example, the investigator can use an interface similar to that of a file browser and is able to navigate the directory tree and choose which files to acquire.
Semi-automatic selective imaging is where a forensic investigator decides which file types or categories of information to capture. This may be based on file extension, file signature, or file hash, or some other definable criteria. When using a selective approach based on file hashes it is important to record which files are present and their provenance, even though the contents of each file may not be captured. It is also be prudent to record referential hash set information.
Automatic selective imaging is where an investigator selects the source and destination devices and the imager automatically acquires the evidence. This is accomplished in a selective manner according to pre-configured parameters or the particular circumstances pertaining to the case / investigation.
The different operating modes that a selective approach presents to the investigator, combined with the flexibility and many options for classifying and grouping information, potentially makes the task very complex. One of the difficulties with selective imaging is recording the provenance of each item selected. This provides a number of options and there is often more than one metric that can be used to record the provenance of an item of information. For example, the location of a particular file on a disk could be recorded in any or all of the following ways:
= physical sector locations (data runs);
= logical cluster locations within a volume, with the addition of an offset from the beginning of the physical device;
= folder location specified from the root folder. This must include partition reference information.
It is not in general possible to categorise any one of these forms as inherently better than any other; none signifies that the evidence associated with it is in ay way inherently 'better' or has more integrity than that associated with any other method.
Provenance indications are preferably unique, unambiguous, concise, and repeatable. Each method meets these criteria in different ways, dependent upon the technical knowledge of the person trying to understand it. For example the general public, a judge, or a legal professional is likely to be more familiar with the concept of a folder location than a more technical concept such as absolute location or cluster reference. These other 'more technical' provenance descriptions may only complicate matters by introducing more technical vocabulary which in practice detracts from and obscures the real information that is to be presented. In an ideal world all relevant provenential descriptions would be captured though in practice this may not be practical. Nevertheless it is considered desirable to be able to capture multiple indications of provenance associated with any given evidence, rather than be restricted to capturing only one in each case.
This would lead to multiple provenential definitions, for example:
= Primary Provenential Key = Physical sector locations;
= Secondary Provenential Key = Logical cluster locations within a volume with the addition of an offset from the beginning of the physical device;
= Tertiary Provenential Key = Folder location specified from the root folder.
It is also possible to have a DEB containing one or more other DEBs: that is, the content type of a DEB may also itself be a DEB. This ability to encapsulate DEBs within DEBs permits a parallel approach to be taken to the acquisition process, thus combining the acquired evidence into one entity for analysis. One example of this would be the simultaneous acquisition of data from distinct disks making up a RAID set: each disk may be captured, potentially concurrently, in a separate DEB and these DEBs in turn encapsulated in a further DEB. Other examples in which data may be concurrently or hierarchically gathered into DEBs will be apparent to the skilled person.
DEBs also support the duplication of either all or selected information from a given source DEB
whereby to create another DEB, together with an audit trail showing the provenance of the copied information. The audit trail may be shown both in the tag field of the originating DEB
from which the new DEB is created and in the tag field of the new DEB itself.
The original DEB
will contain an indication that an application has extracted certain information, whilst the new DEB will contain an indication of where the information contained in it came from.
DEBs may of course be stored on or transmitted via any form of digital medium including, but not limited to, optical, magnetic and wireless media .
Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person for an understanding of the teachings herein.
Claims (22)
1. A method of capturing digital data, the method comprising the steps of:
copying digital data from a data source into one or more evidence files;
for each evidence file recording data descriptive of at least one of the source and the contents of the digital data in the evidence file;
recording, in a tag file, data indicative of provenance of the digital data in the one or more evidence files.
copying digital data from a data source into one or more evidence files;
for each evidence file recording data descriptive of at least one of the source and the contents of the digital data in the evidence file;
recording, in a tag file, data indicative of provenance of the digital data in the one or more evidence files.
2. A method according any preceding claim in which digital data is copied into a plurality of evidence files.
3. A method according to any preceding claim in which the digital data is selectively copied from the data source into the one or more evidence files.
4. A method according to any preceding claim in which, for each evidence file, the data descriptive of one of the source and contents of the digital data is stored in an index file distinct from the evidence file.
5. A method according to claim 4 in which a distinct index file is created for each evidence file.
6. A method according to any preceding claim in which at least the data descriptive of one of the source and contents of the digital data comprises a digital fingerprint of the digital data.
7. A method according to any preceding claim in which the tag file comprises a digital fingerprint of at least one of the evidence files.
8. A method according to any preceding claim in which the tag file comprises a description of the format of the data descriptive of one of the source and contents of the digital data.
9. A method according to any preceding claim in which the data source is a data storage medium.
10. A method according to any preceding claim in which the data source is a data transmission medium.
11. A method according to any preceding claim in which multiple indications of provenance are associated with at least one given item of the digital data in the one or more evidence files.
12. A program for a computer having respective code portions and data structures to perform the steps of the methods of any one of claims 1-11.
13. Apparatus for capturing digital data, the apparatus comprising:
means for copying digital data from a data source into one or more evidence files;
for each evidence file, means for recording data descriptive of at least one of the source and the contents of the digital data in the evidence file;
means arranged to record, in a tag file, data indicative of provenance of the digital data in the one or more evidence files.
means for copying digital data from a data source into one or more evidence files;
for each evidence file, means for recording data descriptive of at least one of the source and the contents of the digital data in the evidence file;
means arranged to record, in a tag file, data indicative of provenance of the digital data in the one or more evidence files.
14. A data structure for capturing digital data, the data structure comprising:
at least one evidence file for containing digital data copied from a data source;
at least one index file containing data descriptive of at least one of the source and contents of the digital data in the at least one evidence files;
a tag file containing data indicative of provenance of the digital data in the at least one evidence files.
at least one evidence file for containing digital data copied from a data source;
at least one index file containing data descriptive of at least one of the source and contents of the digital data in the at least one evidence files;
a tag file containing data indicative of provenance of the digital data in the at least one evidence files.
15. A method of accessing a data structure according to claim 13, the method comprising the steps of:
identifying one or more evidence files to be accessed;
recording details of the evidence file access in the tag file of the data structure;
recording a new integrity check value in the tag file, responsive to the contents of the tag file including the newly-recorded details of the evidence file access.
identifying one or more evidence files to be accessed;
recording details of the evidence file access in the tag file of the data structure;
recording a new integrity check value in the tag file, responsive to the contents of the tag file including the newly-recorded details of the evidence file access.
16. A method according to claim 15 in which the details of the evidence file access comprise at least one of:
identification of the application performing the evidence file access;
identification of the user requesting evidence file access;
identification of the time of evidence file access;
identification of the application performing the evidence file access;
identification of the user requesting evidence file access;
identification of the time of evidence file access;
17. A method according to any one of claims 16-17 in which the integrity check is a digital fingerprint.
18. A method according to claim 17 in which the digital fingerprint is one of a CRC digits, an MD5 hash, and a SHA hash.
19. Apparatus for accessing a data structure according to claim 14, the apparatus comprising:
means for identifying one or more evidence files to be accessed;
means for recording details of the evidence file access in the tag file of the data structure;
means for recording a new integrity check value in the tag file, responsive to the contents of the tag file including the newly-recorded details of the evidence file access.
means for identifying one or more evidence files to be accessed;
means for recording details of the evidence file access in the tag file of the data structure;
means for recording a new integrity check value in the tag file, responsive to the contents of the tag file including the newly-recorded details of the evidence file access.
20. A method of updating a data structure according to claim 14, the method comprising the steps of:
accessing the data structure to extract evidential data contained within it;
processing evidential data extracted from the data structure to create a new evidence file and corresponding index file;
adding the new evidence file and index file to the existing data structure;
appending continuity information to the tag file of the data structure indicative of the addition of the new evidence file and index file.
accessing the data structure to extract evidential data contained within it;
processing evidential data extracted from the data structure to create a new evidence file and corresponding index file;
adding the new evidence file and index file to the existing data structure;
appending continuity information to the tag file of the data structure indicative of the addition of the new evidence file and index file.
21. Apparatus for updating a data structure according to claim 14, the apparatus comprising:
means for accessing the data structure to extract evidential data contained within it;
means for processing evidential data extracted from the data structure to create a new evidence file and corresponding index file;
means for adding the new evidence file and index file to the existing data structure;
means for appending continuity information to the tag file of the data structure indicative of the addition of the new evidence file and index file.
means for accessing the data structure to extract evidential data contained within it;
means for processing evidential data extracted from the data structure to create a new evidence file and corresponding index file;
means for adding the new evidence file and index file to the existing data structure;
means for appending continuity information to the tag file of the data structure indicative of the addition of the new evidence file and index file.
22. Data structures, methods, apparatus, systems, and programs for computers for digital data capture and processing substantially as described in the foregoing specification and with reference to the accompanying drawings.
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0510878.2 | 2005-05-27 | ||
GBGB0510878.2A GB0510878D0 (en) | 2005-05-27 | 2005-05-27 | Digital evidence bag |
GBGB0607489.2A GB0607489D0 (en) | 2005-05-27 | 2006-04-13 | Digital evidence bag |
GB0607489.2 | 2006-04-13 | ||
PCT/GB2006/001942 WO2006126006A1 (en) | 2005-05-27 | 2006-05-26 | Digital evidence bag |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2609469A1 true CA2609469A1 (en) | 2006-11-30 |
Family
ID=36646153
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002609469A Abandoned CA2609469A1 (en) | 2005-05-27 | 2006-05-26 | Digital evidence bag |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1891483A1 (en) |
AU (1) | AU2006250921A1 (en) |
CA (1) | CA2609469A1 (en) |
WO (1) | WO2006126006A1 (en) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2470198A (en) * | 2009-05-13 | 2010-11-17 | Evidence Talks Ltd | Digital forensics using a control pod with a clean evidence store |
US10440033B2 (en) | 2017-03-16 | 2019-10-08 | Sap Se | Data storage system file integrity check |
US11763270B2 (en) * | 2020-05-14 | 2023-09-19 | RecycleGO Inc. | Systems and methods for facilitating generation of a carbon offset based on processing of a recyclable item |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB9715684D0 (en) * | 1997-07-25 | 1997-10-01 | Computer Forensics Limited | Integrity verification and authentication of copies of computer data |
GB2376389A (en) * | 2001-06-04 | 2002-12-11 | Hewlett Packard Co | Packaging evidence for long term validation |
US7370072B2 (en) * | 2002-07-08 | 2008-05-06 | Electronic Evidence Discovery, Inc. | System and method for collecting electronic evidence data |
US7496959B2 (en) * | 2003-06-23 | 2009-02-24 | Architecture Technology Corporation | Remote collection of computer forensic evidence |
-
2006
- 2006-05-26 WO PCT/GB2006/001942 patent/WO2006126006A1/en not_active Application Discontinuation
- 2006-05-26 EP EP06744010A patent/EP1891483A1/en not_active Withdrawn
- 2006-05-26 AU AU2006250921A patent/AU2006250921A1/en not_active Abandoned
- 2006-05-26 CA CA002609469A patent/CA2609469A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
AU2006250921A8 (en) | 2008-02-21 |
AU2006250921A1 (en) | 2006-11-30 |
EP1891483A1 (en) | 2008-02-27 |
WO2006126006A1 (en) | 2006-11-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20080195543A1 (en) | Digital Evidence Bag | |
US7644138B2 (en) | Forensics tool for examination and recovery and computer data | |
US7640323B2 (en) | Forensics tool for examination and recovery of computer data | |
US8656095B2 (en) | Digital forensic acquisition kit and methods of use thereof | |
US20050210054A1 (en) | Information management system | |
US20060259516A1 (en) | Nondisruptive method for encoding file meta-data into a file name | |
JP4901880B2 (en) | Encoding device, decoding device, methods thereof, program of the method, and recording medium recording the program | |
Quick et al. | Big forensic data management in heterogeneous distributed systems: quick analysis of multimedia forensic data | |
US20050219076A1 (en) | Information management system | |
US20060212794A1 (en) | Method and system for creating a computer-readable image file having an annotation embedded therein | |
US20080282355A1 (en) | Document container data structure and methods thereof | |
Mikus et al. | An analysis of disc carving techniques | |
WO2007067425A2 (en) | Forensics tool for examination and recovery of computer data | |
JP2008097484A (en) | Log management system and forensic investigation method | |
Garfinkel et al. | Advanced forensic format: an open extensible format for disk imaging | |
Barrera-Gomez et al. | Walk This Way: Detailed Steps for Transferring Born-Digital Content from Media You Can Read In-House. | |
US9465858B2 (en) | Systems and methods for authenticating and aiding in indexing of and searching for electronic files | |
CA2609469A1 (en) | Digital evidence bag | |
Flaglien et al. | Storage and exchange formats for digital evidence | |
Pahade et al. | A survey on multimedia file carving | |
US9098730B2 (en) | System and method for preserving electronically stored information | |
Scanlon et al. | Digital evidence bag selection for P2P network investigation | |
WO2015166052A1 (en) | Data acquistion | |
Shayau et al. | Digital forensics investigation reduction model (DIFReM) framework for Windows 10 OS | |
Quick et al. | Digital forensic data reduction by selective imaging |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FZDE | Discontinued |