ETSI TS 103 307 V1.2.1 (2016-10)

CYBER; Security Aspects for LI and RD Interfaces

RTS/CYBER-0023

General Information

• Status: Published
• Publication Date: 03-Oct-2016
• Technical Committee: CYBER - Cyber Security
• Current Stage: 12 - Completion
• Due Date: 26-Oct-2016
• Completion Date: 04-Oct-2016

Standards Content (Sample)

ETSI TS 103 307 V1.2.1 (2016-10)






TECHNICAL SPECIFICATION
CYBER;
Security Aspects for LI and RD Interfaces

---------------------- Page: 1 ----------------------
2 ETSI TS 103 307 V1.2.1 (2016-10)



Reference
RTS/CYBER-0023
Keywords
cyber security, lawful interception, retained data

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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
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.

© European Telecommunications Standards Institute 2016.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TS 103 307 V1.2.1 (2016-10)
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 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Structure of document and list of relevant interfaces . 7
4.1 Introduction . 7
4.2 List of LI and RD items covered in the present document . 8
5 Common techniques . 8
5.1 Introduction . 8
5.2 Hash algorithms . 8
Annex A (normative): Providing assurance for LI or RD material as evidence . 9
A.1 Statement of problem . 9
A.2 Techniques for providing assurance for LI or RD material as evidence . 9
A.2.1 How to use the present document . 9
A.2.2 Types of technique . 10
A.2.3 Techniques in the present document . 10
A.3 Detailed definition for hash-only technique in the context of Retained Data . 10
A.3.1 Summary . 10
A.3.2 Terminology used in clause A.3 . 10
A.3.3 Processes and testing . 11
A.3.3.1 Process at CSP . 11
A.3.3.2 Process at any LEA systems handling the Evidence Data . 11
A.3.3.3 Process for use in court . 11
A.3.3.4 Recommended testing and assurance process at LEA Receiver . 12
A.3.4 Choice of hashing algorithms . 12
A.3.5 Meta-data required . 12
A.3.6 Associating hashes with the Evidence Data . 13
A.3.7 Storing information at the CSP . 13
A.3.8 Other notes . 14
Annex B (informative): Security issues for global, third-party or virtualised functionality for
Retained Data functionality . 15
B.1 Introduction . 15
B.2 Reference model and recommendations for Retained Data . 15
B.2.1 Introduction . 15
B.2.2 Reference models/use cases . 15
B.2.3 Approaches to meeting the challenges . 18
B.2.3.0 Introduction. 18
B.2.3.1 Principle 1: Data in transit protection . 19
B.2.3.2 Principle 2: Asset protection and resilience . 19
B.2.3.3 Principle 3: Separation between consumers . 19
B.2.3.4 Principle 4: Governance framework . 20
B.2.3.5 Principle 5: Operational security . 20
B.2.3.6 Principle 6: Personnel security. 20
ETSI

---------------------- Page: 3 ----------------------
4 ETSI TS 103 307 V1.2.1 (2016-10)
B.2.3.7 Principle 7: Secure development . 21
B.2.3.8 Principle 8: Supply chain security . 21
B.2.3.9 Principle 9: Secure consumer management . 21
B.2.3.10 Principle 10: Identity and authentication . 21
B.2.3.11 Principle 11: External interface protection . 22
B.2.3.12 Principle 12: Secure service administration . 22
B.2.3.13 Principle 13: Audit information provision to consumers . 23
B.2.3.14 Principle 14: Secure use of the service by the consumer . 23
B.2.3.15 Table summarizing the principles . 23
B.2.4 Other recommendations for virtualised or globalized Retained Data . 24
B.2.4.0 Introduction. 24
B.2.4.1 Location information . 24
B.2.4.2 Times and storage . 24
B.2.4.3 Logs, audit and records for evidence . 24
History . 25

ETSI

---------------------- Page: 4 ----------------------
5 ETSI TS 103 307 V1.2.1 (2016-10)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 IPR Policy, no investigation, 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.
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

---------------------- Page: 5 ----------------------
6 ETSI TS 103 307 V1.2.1 (2016-10)
1 Scope
The present document specifies security processes and techniques for LI and RD systems.
The present document is limited to:
1) The provision of evidential assurance of RD material.
2) Security issues around the role for global, third-party or virtualised components for RD systems.
Future versions of the present document will cover:
1) Assurance of the integrity and originator of approvals/authorizations.
2) Security aspects of internal interfaces for Lawful Interception.
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
http://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] FIPS Publication 180-4 (2014): "Secure Hash Standard (SHS)".
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 not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 102 657: "Lawful Interception (LI); Retained data handling; Handover interface for the
request and delivery of retained data".
[i.2] ETSI TS 102 232-1: "Lawful Interception (LI); Handover Interface and Service-Specific Details
(SSD) for IP delivery; Part 1: Handover specification for IP delivery".
[i.3] ETSI TS 102 918: "Electronic Signatures and Infrastructures (ESI); Associated Signature
Containers (AsiC)".
[i.4] CESG guidance: "Cloud Security Guidance: Implementing Cloud Security Principles".
NOTE 1: Available at https://www.cesg.gov.uk/guidance/cloud-security-guidance-implementing-cloud-security-
principles.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TS 103 307 V1.2.1 (2016-10)
NOTE 2: Text extracted from [i.4] and used in the present document is in italics and done according to the Open
Government Licence available at http://www.nationalarchives.gov.uk/doc/open-government-
licence/version/1/open-government-licence.htm.
[i.5] ETSI TS 102 656: "Lawful Interception (LI); Retained Data; Requirements of Law Enforcement
Agencies for handling Retained Data".
[i.6] ETSI GS NFV-SEC 010: "Network Functions Virtualisation (NFV); NFV Security; Report on
Retained Data problem statement and requirements".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI TS 102 657 [i.1] and the following
apply:
third party: organization other than the CSP or LEA who is engaged to assist in providing RD or LI services
NOTE: Often the phrase "Trusted Third Party" is used. Clearly the CSP or LEA are expected to engage Third
Parties whom they consider to be trusted.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
CESG Communications Electronic Security Group
CSP Communications Service Provider
LEA Law Enforcement Agency
LI Lawful Interception
PDF Portable Document Format
RD Retained Data
SHA Secure Hash Algorithm
XML Extensible Markup Language
4 Structure of document and list of relevant interfaces
4.1 Introduction
The present document considers the list of particular information flows and interfaces for RD and LI specified in
clause 4.2. It examines them from a security (confidentiality, integrity and authenticity) perspective and specifies
implementation details (technologies, algorithms, options, minimum requirements on keys, etc. ).
An underlying reference model for LI is given in ETSI TS 102 232-1 [i.2] and an underlying reference model for RD is
given in ETSI TS 102 657 [i.1].
Certain techniques are applicable to more than one information flow or interface. Generic techniques are addressed in
clause 5.
For each information flow or interface, the present document contains the following information (where applicable):
• Statement of the problem, including reference model.
• Identification of the threats and risks to the extent it is appropriate to publish in a standard.
• Statement of the techniques which are recommended as a solution.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TS 103 307 V1.2.1 (2016-10)
4.2 List of LI and RD items covered in the present document
The present document addresses the following LI and RD items:
1) Providing evidential assurance of LI or RD material (annex A).
2) Security issues around the role for global, third-party or virtualised components of Retained Data facilities
(annex B).
The following topics will be covered in future versions of the present document:
1) Assurance of the integrity and originator of approvals/authorizations.
2) Security aspects of internal interfaces for Lawful Interception.
5 Common techniques
5.1 Introduction
The following techniques are used in a number of the annexes of the present document:
• Algorithms for hashing data.
• The following techniques will be included in future versions of the present document:
• Digital signature algorithms.
• Procedures for Trusted timestamp.
• Transport-layer security.
5.2 Hash algorithms
The SHA-256 algorithm shall be as defined in FIPS Publication 180-4 [1].
The SHA-512 algorithm shall be as defined in FIPS Publication 180-4 [1].
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TS 103 307 V1.2.1 (2016-10)
Annex A (normative):
Providing assurance for LI or RD material as evidence
A.1 Statement of problem
The requirement is to provide assurance about the integrity of the LI or RD material (i.e. to help with assurance that it
has not been altered during the course of delivery and/or storage with end user authorities) and to provide assurance
about the originator of the material (i.e. the organization that produced it). The present document does not look at any
requirement for confidentiality in this annex.
The goal of this clause is to add assurance to LI or RD material if it is presented as evidence in court. The present
document does not attempt to examine legal aspects and no assurance is given that the process in the present document
provides a complete or adequate level of assurance for any particular jurisdiction.
The reference model for this clause consists of two parties:
• The originator: the party that creates the material and wishes to provide assurance about its integrity and
origin.
• The receiver: the party that wishes to check the integrity and originator of the material.
In a typical situation:
• The originator is the CSP, and the information flow starts at the point where material is selected by the CSP
for use as RD or LI. The present document does not examine the integrity of existing CSP business records.
• The receiver is wherever there is a requirement to check the integrity and origin. This can include:
- immediately upon receiving the material at a government/police agency; or
- as a check by police or prosecution teams prior to court; or
- for checking at any time during court proceedings.
The information contained within the flow is not defined within the present document, except where it is noted that
parameters (such as identifiers or timestamps) would be needed in order to meet the requirements.
A.2 Techniques for providing assurance for LI or RD
material as evidence
A.2.1 How to use the present document
The present document lists a set of techniques which may be used to help provide assurance of LI or RD material used
in evidence.
A threat analysis should be performed on a national basis to determine the set of techniques which is appropriate for any
given jurisdiction or situation.
Systems should be designed to avoid a "bid-down" attack where techniques can be selected which are not appropriate
for the threats they are trying to mitigate.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TS 103 307 V1.2.1 (2016-10)
A.2.2 Types of technique
Techniques for assuring evidence can be categorized as:
• Process-based: It is possible to assure evidence by demonstrating that a process was followed in accordance
with approved procedures.
EXAMPLE 1: Use a published procedure for how a Retained Data response file is stored, and demonstrate that
these procedures had been followed.
• Cryptography-based: It is possible to assure evidence based on cryptographic assurance of the integrity and
origin of material.
EXAMPLE 2: If material is signed using a private key which has been stored securely, there is cryptographic
assurance that it was produced by the owner of the private key.
Many countries/jurisdictions use a mix of both process-based techniques and cryptographic techniques. The present
document does not state that one type of technique is fundamentally better than the other. It is national choice whether
to use process-based techniques, or cryptographic techniques, or a mixture of the two.
A.2.3 Techniques in the present document
The present document lists two cryptography-based techniques:
• "Hash-only technique": Clause A.3 specifies a technique by which hashes give assurance to Retained Data
records. This technique provides assurance that evidence has not been altered from originator to receiver. It
places a requirement on the sender to keep a record of the hashes it created.
• "Digital-signature technique": This technique provides assurance of the integrity and origin of the material.
The details of this technique (in an LI context) is given in ETSI TS 102 232-1 [i.2]. It relies on the
cryptographic material being stored securely.
A.3 Detailed definition for hash-only technique in the
context of Retained Data
A.3.1 Summary
This clause defines a technique based on hashing without using signatures. The present document describes this
technique in the context of assuring the integrity of Retained Data records from the point when a request is answered by
the CSP onwards (e.g. through to its use in court). However, it can be used in other contexts e.g. for material other than
Retained Data or for assuring Retained Data at other stages.
This clause highlights how the present document can be used in conjunction with ETSI TS 102 657 [i.1].
A.3.2 Terminology used in clause A.3
The terms "Request" and "Response" are defined in ETSI TS 102 657 [i.1].
The "Evidence Data" is the response generated by the CSP which is required to be assured for use in evidence. The
Evidence Data is considered to be immutable or "atomic" i.e. it is not possible to discard part of the evidence and assure
the remainder. If information has sub-components that can be used independently then each component is considered to
be a single piece of Evidence Data and is hashed separately. Clause A.3.6 details how the Evidence Data and hashes can
be associated.
The "Unique Identifier" for Evidence Data (UniqueID) is a unique identifier for a single piece of Evidence Data. If
ETSI TS 102 657 [i.1] is used, the RequestID can be used as the UniqueID.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TS 103 307 V1.2.1 (2016-10)
The "LEA Receiver" is the function on the Police/LEA side of the interface which is the first function to receive the
Evidence Data. Clause A.3.3.4 provides recommendations for the LEA Receiver.
A.3.3 Processes and testing
A.3.3.1 Process at CSP
Creation of response: Once the Evidence Data is generated, the CSP shall produce a hash or hashes, using the
algorithms defined in clause A.3.4 and the meta-data from clause A.3.5. Clause A.3.6 details how the Evidence Data
and hashes can be associated The CSP shall then store information as described in clause A.3.7. Deletion occurs in
accordance with the relevant record retention policy and is out of scope of the present document. There is no need (from
the point of view of the present document) for the Evidence Data to be kept once it is known to be successfully
delivered.
Retrieval of a hash for a given piece of Evidence Data: The CSP shall respond promptly to requests for providing a
hash. A unique ID shall be submitted to the CSP, and the CSP shall respond with all known hashes for that Unique ID.
The method by which this occurs shall be in accordance with national processes - for example manually (email,
telephone, in writing) or via automated services.
A.3.3.2 Process at any LEA systems handling the Evidence Data
Wherever the LEA stores the Evidence Data, the hashes should be stored with it, maintaining the association as listed in
clause A.3.6.
A.3.3.3 Process for use in court
Initial checks: As soon as it is clear that the Evidence Data will be used in evidence, the following checks should be
performed:
• Calculate the hash(es) of the Evidence Data. Note that various web site provide free software for on-line or
off-line hash checking, though the present document does not guarantee the accuracy of any particular
software.
• Check that the calculated hashes match the hashes associated with the Evidence Data.
• Go to the CSP and request at least one of the hashes for the Evidence Data, and check it matches.
Use in court: If the integrity of the Evidence Data is challenged or questioned in court, in some contexts it may be
beneficial to note the documented process, that has been followed to create hashes of this material at the point at which
the request was answered (e.g. a reference to the present document and any appropriate national standard could be
given).
If further corroboration is required, the court can request the hash(es) of the Evidence Data based on its UniqueID in
accordance with clause A.3.3.1. National processes will determine which type of check is acceptable (e.g. an on-line or
automated check and/or a CSP provides a response by telephone or a written response). That the hash of the Evidence
Data matches the hash produced by the CSP is a matter of demonstrating this to the court if it is necessary. Note that
only one of the two hash algorithms needs to be used: provided the hash matches through one algorithm, then this
provides assurance that the material is unchanged from the point it was created.
ETSI

---------------------- Page: 11 ----------------------
12 ETSI TS 103 307 V1.2.1 (2016-10)
A.3.3.4 Recommended testing and assurance process at LEA Receiver
The recipient (LEA Receiver, the first point on the LEA side to receive the RD) should store and test the hashes as
described in this clause. The functionality in this clause (A.3.3.4) is not a mandatory part of demonstrating assurance of
material used in court.
Receiving a response: Immediately on receiving the Evidence Data, the LEA Receiver should check that the hashes of
the Evidence Data are correct (i.e. take the hashes of the Evidence Data and check they are the same as the hashes
supplied) and check that the required information (see clause A.3.5) is present and correct (or, if it is not possible to
check it is correct, it should be checked that it is formatted correctly
...