ETSI TS 103 643 V1.2.1 (2022-01)

TECHNICAL SPECIFICATION
Techniques for assurance of
digital material used in legal proceedings

2 ETSI TS 103 643 V1.2.1 (2022-01)

Reference
RTS/CYBER-0079
Keywords
information assurance
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3 ETSI TS 103 643 V1.2.1 (2022-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Basic principles . 7
4.1 Summary . 7
5 Definition of a Basic Digital Evidence Bag . 7
5.1 Reference model . 7
5.2 Inputs of digital data . 8
5.2.1 Nature of inputs . 8
5.2.2 A unique identifier for each input . 8
5.2.2.1 Identifiers for case-specific input material . 8
5.2.2.2 Identifiers for reference input material . 8
5.2.3 Time and location information for input material . 8
5.2.4 Format of input material . 9
5.3 Applying Purely Digital Transformations and Assured Digital Transformations . 9
5.3.1 Definition of a Purely Digital Transformation . 9
5.3.2 Use of PDT in a Digital Evidence Bag . 9
5.3.3 Definition of an Assured Digital Transformation . 10
5.3.4 Use of ADT in a Digital Evidence Bag. 10
5.4 Details for creating the output . 11
6 Definition of other Digital Evidence Bags . 11
6.1 Introduction . 11
6.2 Definition of a DEB+H . 11
6.2.1 General . 11
6.2.2 Use of hashing in a DEB+H . 11
6.3 Definition of a DEB+IA . 12
6.4 Definition of a DEB+HIA . 12
Annex A (informative): Context . 13
A.1 Purpose of the present document . 13
A.2 Void . 13
A.3 Choosing which type of DEB to use . 13
A.4 Void . 13
Annex B (informative): Examples . 14
B.1 Introduction . 14
B.2 Examples of transformations which are not PDT . 14
B.3 Examples regarding accuracy and completeness of input material . 14
B.4 Example of linking to physical evidence. 15
ETSI
4 ETSI TS 103 643 V1.2.1 (2022-01)
Annex C (informative): Data Integrity, Provenance, Continuity and Validity . 16
C.1 Introduction . 16
C.2 Integrity . 16
C.3 Provenance . 16
C.4 Continuity . 16
C.5 Validity . 16
C.6 Other considerations . 17
Annex D (informative): Examples of functions for performing purely digital transformations . 18
D.1 Introduction . 18
D.2 Finding items in common between two or more lists . 18
D.3 Filtering of a list of items based on a criterion . 18
D.4 Adding additional data from reference material . 18
D.5 Presentation of material . 18
D.6 Change of formatting or codec . 19
Annex E (informative): Considerations when handling certain data types . 20
E.1 Introduction . 20
E.2 Phone numbers . 20
E.3 Names . 20
E.4 Addresses . 20
E.5 Locations . 21
E.6 Dates and times . 21
E.7 Identifiers . 21
E.8 Text in general . 21
Annex F (informative): Testing a DEB. 22
F.1 Introduction . 22
F.2 Conformance statement . 22
F.3 Checking when challenged in legal proceedings . 22
Annex G (normative): Hash assurance function . 23
G.1 Requirements . 23
G.1.1 Functional requirements . 23
G.1.2 Non-functional requirements . 23
G.2 Example of a hash assurance function (informative) . 24
G.2.1 Introduction . 24
G.2.2 Specification of primary functionality . 24
G.2.3 Specification of secondary functionality . 25
G.2.4 Specification of tertiary functionality . 25
G.2.5 Use cases . 25
Annex H (informative): Change History . 27
History . 28

ETSI
5 ETSI TS 103 643 V1.2.1 (2022-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Cyber Security (CYBER).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI TS 103 643 V1.2.1 (2022-01)
1 Scope
The present document defines a process of receiving, transforming and outputting material that can be assured digitally.
The process is called the "Digital Evidence Bag" (DEB). The present document identifies the ways that a DEB can be
used to provide assurance of material used in legal proceedings. Specifically, the assurance of the material is not
dependent on the process having been carried out by a qualified or trained human expert.
The present document is designed to be used in situations where a risk assessment of the handling of digital material has
identified that extra assurance of the integrity, provenance, continuity and validity of the digital data is required.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
[2] ETSI TS 103 307: "CYBER; Security Aspects for LI and RD Interfaces".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[i.1] ISO/IEC 17025: "General requirements for the competence of testing and calibration laboratories".
[i.2] Lives and Opinions of Eminent Philosophers, Diogenes Laërtius (c. 225 CE).
[i.3] Navigation and Nautical Astronomy, James Inman (1835).
[i.4] ISO 8601: "Date and time -- Representations for information interchange".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
case-specific input material: input material for a Digital Evidence Bag that is specific to the particular investigation or
case
ETSI
7 ETSI TS 103 643 V1.2.1 (2022-01)
Digital Evidence Bag (DEB): process of storing digital evidence which can be assured digitally
Purely Digital Transformation (PDT): transformation in which a repeatable, deterministic, pre-specified, fail-safe,
well-defined digital function is performed on entirely digital data
NOTE: See clause 5.3.1 for more information.
reference input material: relevant material (if any) which is used to support the case-specific input material by adding
context or background
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADT Assured Digital Transformation
B-DEB Basic Digital Evidence Bag
DEB Digital Evidence Bag
DEB+H Digital Evidence Bag with Hashing
DEB+HIA Digital Evidence Bag with Hashing and Input Assurance
DEB+IA Digital Evidence Bag with Input Assurance
DIPCV Data Integrity, Provenance, Continuity and Validity
GDPR General Data Protection Regulation
LED Law Enforcement Directive
PDT Purely Digital Transformation
4 Basic principles
4.1 Summary
The present document gives a definition for a "Digital Evidence Bag", which is a process for storing and transforming
digital material. Annex A provides an informative description of when this process is intended to be used.
The present document defines and specifies requirements for the following types of Digital Evidence Bag:
1) A Basic Digital Evidence Bag (B-DEB) (see clause 5).
2) A Digital Evidence Bag with Hashing (DEB+H) (see clause 6).
3) A Digital Evidence Bag with Input Assurance (DEB+IA) (see clause 6).
4) A Digital Evidence Bag with Hashing and Input Assurance (DEB+HIA) (see clause 6).
Annex F provides recommendations for testing a DEB.
NOTE: A Digital Evidence Bag with Digital Signature would also meet many of the same goals as the Digital
Evidence Bag with Hashing and Input Assurance and this is being considered for a future version.
5 Definition of a Basic Digital Evidence Bag
5.1 Reference model
The model for a Basic Digital Evidence Bag is as shown in Figure 1.
ETSI
8 ETSI TS 103 643 V1.2.1 (2022-01)
Apply a set of
Check inputs
Inputs of
Create output
PDTs or ADTs
(clause 5.2)
digital data (clause 5.4)
(clause 5.3)
Figure 1: Model for Basic Digital Evidence Bag
5.2 Inputs of digital data
5.2.1 Nature of inputs
There are two types of input material: case-specific input material and reference input material (as defined in clause 3).
EXAMPLE: Examples of reference input material are maps or publicly available reference data.
Basic DEBs shall follow the specifications for input material as listed in clauses 5.2.2 to 5.2.4.
5.2.2 A unique identifier for each input
5.2.2.1 Identifiers for case-specific input material
For a Basic DEB, each input of case-specific input material (see clause 3) shall have a unique identifier attached to it.
One of the two following approaches shall be used:
1) The identifier shall consist of:
a) an identifier supplied by the originating organization; and
b) a unique identifier for the originating organization. A globally-unique identifier shall be created for the
originating organization, using a combination of a nationally-unique identifier together with a country
code.
2) The identifier shall be a randomly chosen globally unique identifier as defined in IETF RFC 4122 [1].
Each piece of case-specific input material should include where relevant an identifier of a request that prompted the
generation of the input.
5.2.2.2 Identifiers for reference input material
For a Basic DEB, the reference input material (see clause 3) should also have an identifier to make it clear where it
came from, and should also identify the time it was collected if that is significantly different from the time the material
is being submitted to the DEB.
5.2.3 Time and location information for input material
The time information in a Basic DEB shall consist of the following:
• All time information as supplied by the originating organization. The input material should contain time and
date information, including indication of the time zone, for the point at which the data was generated or
created (or for the period over which the data was generated).
• DEB Entry Time: A timestamp shall be added to indicate the time and date, including indication of the time
zone, the data was received at the Digital Evidence Bag.
In the case that the time of creation is clearly indicated by the originating organization, it shall be checked that the DEB
Entry Time is after the time of creation of the material.
ETSI
9 ETSI TS 103 643 V1.2.1 (2022-01)
The location of collection of information should be included where the point of collection is not necessarily fixed to one
place and is relevant to the value of the material collected.
EXAMPLE: A contract has been placed with a laboratory to provide information, and the contract includes a
statement of the formats in which the data will be provided.
5.2.4 Format of input material
The format for each input file to a Basic DEB should be known or clear (i.e. known via a communication in advance of
sending the data, or clear from the evidence file itself). Each input file should be checked syntactically for data formats
where there are suitable automated checks.
EXAMPLE: If data is submitted in XML and the XML schema is known and agreed, then each input file is
checked against the schema.
5.3 Applying Purely Digital Transformations and Assured Digital
Transformations
5.3.1 Definition of a Purely Digital Transformation
A Purely Digital Transformation (PDT) is one in which a repeatable, deterministic, pre-specified, fail-safe, well-defined
digital function is performed on entirely digital data.
Specifically:
• It is repeatable in that if the step is performed again by a different computer or operator, in a different
environment, in a different country or at a different time, the outcome is always the same.
• It is deterministic in that the same inputs to the process always give the same outputs, which is not dependent
on the training or skill level of an operator.
• It is pre-specified in that the full details of the process are known to all relevant parties in advance and (ideally
but not essentially) the details are published.
• It is fail-safe in that its failure modes are easily distinguishable from successful outcomes (in particular, that a
failure mode looks very different from a successful output with no records in it).
• It is well-defined in that the version numbering is present and accurate and that the formatting is clear and
specified in all places.
• It is digital in that its input and output are digital.
5.3.2 Use of PDT in a Digital Evidence Bag
Within the Digital Evidence Bag, one or more PDTs (as defined in clause 5.3.1) may be applied.
For each transformation, the DEB shall check:
• That the formatting and definition of input files is clear.
• That any standards referred to have a correct version number and are designed for the purpose in question.
• That the input(s) each has an identifier for the material in question.
The DEB shall record:
• The time and date that the transformation took place, ensuring time zone is clear.
• A unique identifier to the output.
• An identification of the process that took place and an identifier to the entity that performed it.
ETSI
10 ETSI TS 103 643 V1.2.1 (2022-01)
The recommendations in Annex E should be followed when handling the types of data listed in Annex E. Examples of
PDT are given in Annex D.
5.3.3 Definition of an Assured Digital Transformation
An Assured Digital Transformation (ADT) is one in which a documented, fail-safe task is performed on entirely digital
data by a suitably qualified person.
Specifically:
• The task is documented, in that there is a document listing how the task is to be performed, which was
available to the person performing the task and is available to be referenced during legal proceedings. The
document lists the inputs required and, where appropriate, the format of each input. The areas that require
human judgement or skill are explicitly stated in the documentation. If the task needs suitable facilities, this is
stated in the documentation. If the task needs suitable software, this is stated in the documentation.
NOTE 1: The present document does not define what suitable facilities or suitable software are.
NOTE 2: The present document records what was required and what was used so that the court can decide whether
it was suitable, perhaps by referring to other standards in this area e.g. ISO/IEC 17025 [i.1].
• The task is fail-safe, in that the documentation lists the common failure modes, showing how failure modes are
easily distinguishable from successful outcomes (in particular, that a failure mode looks very different from a
successful output with no records in it).
• The task is digital in that its input and output are digital.
• The person is qualified for the task, in that they have suitable recorded experience or qualifications to cover
the areas of the task that have been identified as requiring human judgement or skill.
NOTE 3: The present document does not specify what qualifications would count as suitable.
NOTE 4: The purpose of the present document is to define how to create a record of the task that was performed,
including details of the person who performed the task including their qualifications. The content of the
record can allow a court to establish whether it considered the qualification suitable for the task, perhaps
by referring to other standards in this area.
5.3.4 Use of ADT in a Digital Evidence Bag
Within the Digital Evidence Bag, one or more ADTs (as defined in clause 5.3.3) may be applied.
For each transformation, the DEB shall:
• Check formatting of input files is clear (in line with the documentation).
• Check that the input(s) each has an identifier.
The DEB shall record:
• The time and date that the transformation took place, ensuring time zone is clear.
• A unique identifier for the output.
• An identification of the process that took place, giving a link to the documentation that describes the required
human judgement, facilities and software (described in clause 5.3.3).
• A unique way to identify the person who performed it. Where possible, this should be done using an identifier
for an organization (e.g. the person's employer) together with a unique ID within that organization. This
requirement may also be met using a country code plus a unique identifier for a person within a country.
• The qualification of the person who performed, as described in clause 5.3.3. No unrelated qualifications shall
be added.
• The location of performing the task, if the task needed suitable facilities (as stated in the documentation).
ETSI
11 ETSI TS 103 643 V1.2.1 (2022-01)
• The software used with unique name and version number, if the task needed suitable software (as stated in the
documentation).
5.4 Details for creating the output
The Basic DEB output file shall contain the following information:
• List of all input files, including identifiers (as defined in clause 5.2.2) and the DEB entry time (clause 5.2.3).
• For each transformation that was applied, a list of the details for that transformation from clause 5.3.2 (for
PDTs) or 5.3.4 (for ADTs).
• The software name and version that was used.
NOTE: There can also be requirements for the material in the Digital Evidence Bag to be deleted in a complete
and assured way. These requirements are out of scope of the present document, though it is noted that a
number of the techniques in the present document (e.g. list of all processes that have been applied,
identification of inputs and outputs of each stage) can help to demonstrate a list of material which needs
to be deleted.
6 Definition of other Digital Evidence Bags
6.1 Introduction
Clause 6 specifies the following types of Digital Evidence Bag:
• DEB+H (with Hashing).
• DEB+IA (with Input Assurance).
• DEB+HIA (with Hashing and Input Assurance).
NOTE: A Digital Evidence Bag with Digital Signature would also meet many of the same goals as the Digital
Evidence Bag with Hashing and Input Assurance and this is being considered for a future version.
Each of the definitions builds on the definition of a Basic DEB in clause.
Clause A.3 explains when it can be appropriate to choose each of the different types of DEB.
6.2 Definition of a DEB+H
6.2.1 General
A Digital Evidence Bag with Hashing (DEB+H) shall meet the specification of a Basic DEB (clause 5). In addition, it
shall use hashing as specified in clause 6.2.2.
NOTE: A Digital Evidence Bag with Hashing would typically be used in situations where assurance was required
that material had not been changed from the point at which it was submitted to the DEB (and potentially
earlier than this, depending on when the hash was taken) through to the point it was used in court. See
clause A.3 for more information.
6.2.2 Use of hashing in a DEB+H
A DEB+H shall create a single input file with all input material. The input material shall include all identifiers as
defined in clause 5.2.2 and the DEB entry time as defined in clause 5.2.3.
EXAMPLE: A number of pieces of input material could be turned into a single file through use of zip.
ETSI
12 ETSI TS 103 643 V1.2.1 (2022-01)
The single input file shall be hashed using the algorithms from ETSI TS 103 307 [2], clause A.3.4.
NOTE 1: This requires the use of two (or more) algorithms, allowing for new algorithms to be added and older ones
to be removed without dependence on a single algorithm (it facilitates crypto-agility).
The hash shall be stored in a manner which provides assurance that it cannot be changed over time. The underlying goal
is that the assurance is strong enough to satisfy the purposes identified in the risk assessment (see clause A.3).
Assurance shall be provided using one or both of the following mechanisms:
1) Through examining the physical, cryptographic or procedural controls that are in place at the storage site
(e.g. examples are given for assuring storage at the Communications Service Providers in ETSI
TS 103 307 [2]).
2) Through storage of hashes at a dedicated function which uses publication of material (along with clear
cryptographic controls) to demonstrate that hashes are unchanged. A function as specified in Annex G may be
used to perform the hash assurance role.
When assurance is required, it is sufficient to check that the hash of the input material matches the hash that was stored
and assured as described above. Further examples are given on this point in ETSI TS 103 307 [2] in clause A.3.
NOTE 2: There are advantages to assuring that a hash is unchanged (rather than demonstrating that the material
itself is unchanged): the material can contain details that need to be kept confidential i.e. this is a
technique that assists in the preservation of privacy.
Hashes may also be created at other stages of the process. If used, such hashes shall be in addition to and completely
independent of the hash described in this clause. They shall follow the same processes as the hash of the single input
file (i.e. shall use the algorithms described in this clause, shall be stored as described in this clause and may be checked
as described in this clause).
If ADTs are used in the DEB, then it is noted that the processing inside the DEB is not necessarily completely
deterministic and repeatable (as it contains an element of human judgement). Therefore consideration should be given
to creating an additional hash covering the information in the DEB output file as defined in clause 5.4.
6.3 Definition of a DEB+IA
A DEB+IA shall follow the specification in clause 5 for the definition of a Basic DEB.
Additionally, the DEB+IA shall identify the delivery protocol or technique which was used to input the material to the
DEB. The DEB+IA shall log any credentials that were provided or were necessary in order to use the specified delivery
protocol or technique. The output file shall contain the credentials used.
EXAMPLE 1: If the material was delivered over a secured private network, then there is assurance that the
material originated from someone who had access to the secured private network. The credentials
would be the log-on details (e.g. username and time) that were used to access the network.
EXAMPLE 2: If material is delivered to a specific physical or network location (e.g. a specific folder) then there
is assurance that the material originated from someone who had permission to access that location.
The credentials would be the log-on details that were given which enabled the user to access the
location.
NOTE: Situations would need to be assessed on a case-by-case basis to see whether the protocol was appropriate
for meeting the risks identified (see clause A.3).
6.4 Definition of a DEB+HIA
A DEB+HIA shall follow the specifications in both clauses 6.2 and 6.3 in addition to the specification of a Basic DEB
in clause 5.
Clause A.3 explains when it can be appropriate to each of the different types of DEB.

ETSI
13 ETSI TS 103 643 V1.2.1 (2022-01)
Annex A (informative):
Context
A.1 Purpose of the present document
The present document considers the assurance of handling and processing of material which is potentially to be used in
legal proceedings (often referred to as assurance of evidence in court). Material goes through various steps prior to its
presentation in legal proceedings; this is sometimes called the chain of evidence.
The present document notes that, in some situations, it is possible and beneficial to provide digital assurance (i.e. using
digital and/or cryptographic techniques) to a set of processes or transformations of the material. The present document
provides a specification for a process (called a Digital Evidence Bag or DEB) which can be used for handling digital
material.
The processes outlined in the present document do not (in general) provide assurances about whether the material was
correct or accurate at the point it was originally collected or created. The goal of the present document is to provide
assurance of the subsequent processes of handling, storing, transforming and presenting the material.
A.2 Void
A.3 Choosing which type of DEB to use
It is not essential to use a DEB for all digital evidence. The purpose of the present document is to provide a set of tools
(DEB or DEB+H,or DEB+HIA) which are chosen where additional assurance is deemed to be appropriate for digital
material. In determining whether to use a DEB (or which type of DEB to use), a risk assessment should be made. The
risk assessment would determine and analyse the potential challenges to the material when it is presented in court, and
to highlight those which are likely to result in a significant and realistic challenge. The risk assessment should consider
those aspects of Data Integrity, Continuity, Provenance and Validity as described in Annex C. Once the risks are
understood, it can be seen whether the DEB (or DEB+H or DEB+HIA) would be able to mitigate the risks, which
determines whether (or which) DEB it is appropriate to use.
A.4 Void
ETSI
14 ETSI TS 103 643 V1.2.1 (2022-01)
Annex B (informative):
Examples
B.1 Introduction
This clause contains examples which illustrate concepts from the main body of the present document. These are
illustrations but do not change or supersede the normative text which they are supporting.
B.2 Examples of transformations which are not PDT
This clause contains details to illustrate the definition of a Purely Digital Transformation (see clause 5.3.1).
The following characteristics would demonstrate that a transformation did not meet the definition in clause 5.3.1
i.e. that the transformation is not purely digital:
• Something which requires human skill or judgement.
• Something in which an untrained user could create apparently correct answers which differed from those that a
trained user would create:
- It is acceptable for a PDT to need a basic level of training e.g. which button to press to start the process.
• Something which requires calibration or expert maintenance in order to avoid errors:
- It is acceptable for purely digital techniques to need updates e.g. refresh of algorithms.
• A transformation which uses an analogue measurement as part of the transformation.
• A transformation where the same inputs could get a different output depending on external factors e.g. the
weather:
- It is acceptable for a PDT to report an error or fail to complete in some situations e.g. a power cut,
provided these situations do not result in an incorrect but apparently successful output.
B.3 Examples regarding accuracy and completeness of
input material
The accuracy and completeness of the input data is not part of the normative requirements of the present document.
The following examples can be helpful to aid consideration of this issue:
• In some cases, material originates from data captured by or measurements taken by members of law
enforcement e.g. at a crime scene. In these cases there is control over the chain of evidence from the point the
data is created i.e. through the chain of evidence it is straightforward to be aware of the training, expertise and
oversight of those involved.
• In other cases, the data comes from a third-party system e.g. call records retained by a Communications
Service Provider. In these cases, it would be possible to examine existing assurances about the accuracy and
completeness of the data. For example, if the data came from billing systems, then it is likely that there are
existing standards and processes which can give assurances about the accuracy and completeness of billing
records. These can be useful in providing assurance about the material.
• In many examples there will be theoretical risks regarding the accuracy and completeness of the input
material. These are considered in light of the risk assessment outlined in clause A.3, noting that it is not
necessary to discount or ignore material because of an unlikely or theoretical risk that it is incorrect.
ETSI
15 ETSI TS 103 643 V1.2.1 (2022-01)
B.4 Example of linking to physical evidence
It is possible to make a link from physical evidence to digital identifiers through the use of sprays/gels/liquids
containing a substance which is uniquely linkable to a speci
...