ETSI TS 103 436 V1.1.1 (2016-08)

Reconfigurable Radio Systems (RRS); Security requirements for reconfigurable radios

DTS/RRS-03012

General Information

• Status: Published
• Publication Date: 24-Aug-2016
• Technical Committee: RRS 3 - RRS Security, Certification & Declaration of Conformity
• Current Stage: 12 - Completion
• Due Date: 01-Sep-2016
• Completion Date: 25-Aug-2016

Standards Content (Sample)

ETSI TS 103 436 V1.1.1 (2016-08)






TECHNICAL SPECIFICATION
Reconfigurable Radio Systems (RRS);
Security requirements for reconfigurable radios

---------------------- Page: 1 ----------------------
2 ETSI TS 103 436 V1.1.1 (2016-08)



Reference
DTS/RRS-03012
Keywords
security, software
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 436 V1.1.1 (2016-08)
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 . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Review of objectives and high level requirements . 8
5 Countermeasure framework . 11
5.1 Notes for interpretation . 11
5.2 Identity management and authentication . 11
5.3 Document integrity proof and verification . 12
5.3.1 Overview of process . 12
5.4 Non-repudiation framework . 13
5.4.1 Overview of non-repudiation . 13
5.4.2 Stage 1 model for non-repudiation . 14
5.4.2.1 Procedures . 14
5.4.2.1.1 Provision/withdrawal . 14
5.4.2.1.2 Normal procedures . 14
5.4.2.1.3 Exceptional procedures. 15
5.4.2.2 Interactions with other security services . 15
6 Information flows and reference points (stage 2) . 15
6.1 Overview . 15
6.2 Confidentiality . 17
6.3 Integrity . 18
6.4 Identity management . 18
6.5 Non-Repudiation services . 19
6.5.1 Non-repudiation stage 2 models . 19
7 Protocol sequences and data content (stage 3) . 20
7.1 Confidentiality . 20
7.1.1 Data in transit (encryption) . 20
7.1.2 Data in storage (access control) . 20
7.2 Integrity . 21
7.2.1 Data in transit . 21
7.2.2 Data in storage . 21
7.2.2.1 Single storage point . 21
7.2.2.2 Distributed storage points . 21
7.3 Combined authentication and integrity using digital signature . 22
7.4 Non-repudiation service . 22
8 Cryptographic algorithm and key considerations . 23
8.1 Symmetric cryptography . 23
8.2 Asymmetric cryptography . 23
Annex A (informative): Cost benefit analysis for countermeasure application . 24
A.1 Sample calculation . 24
A.2 Standards design . 26
A.3 Implementation . 26
ETSI

---------------------- Page: 3 ----------------------
4 ETSI TS 103 436 V1.1.1 (2016-08)
A.4 Operation . 27
A.5 Regulatory impact . 27
A.6 Market acceptance . 27
Annex B (informative): Password policy guide . 29
Annex C (informative): Key lifetime and verification guidelines . 31
C.1 General . 31
C.2 Symmetric cryptography . 31
C.3 Asymmetric cryptography . 31
C.4 Export control . 31
Annex D (informative): PKI considerations for RRS . 33
D.1 What is a Public Key Infrastructure? . 33
D.2 Authorities in RRS and their PKI role . 34
D.3 Assignments of RRS roles to PKI . 36
D.3.1 Model 1: New Root Authority for RRS in the EU . 36
D.3.2 Model 2: Existing authorities assigning one entity as root . 36
D.4 Alternative models to PKI for key management . 36
D.4.1 General considerations . 36
D.4.2 Self signed certificates . 36
History . 37


ETSI

---------------------- Page: 4 ----------------------
5 ETSI TS 103 436 V1.1.1 (2016-08)
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 Reconfigurable Radio Systems
(RRS).
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 436 V1.1.1 (2016-08)
1 Scope
The present document defines the security requirements for reconfigurable radio systems arising from the the use case
analysis in ETSI TR 103 087 [i.1]. The present document applies to the lifecycle of Radio Application Packages
between a Radio application store and an RRS Reconfigurable Equipment.
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] Federal Information Processing Standard (FIPS) 202, SHA-3 Standard: Permutation-Based Hash
and Extendable-Output Functions.
[2] Federal Information Processing Standards (FIPS) 186-4, Digital Signature Standard (DSS).
[3] Federal Information Processing Standards Publication (FIPS) 180-4, Secure Hash Standard.
[4] Federal Information Processing Standards Publication (FIPS) 197, Advanced Encryption Standard.
[5] Recommendation ITU-T X.509: Information technology - Open Systems Interconnection - The
Directory: Public-key and attribute certificate frameworks.
[6] ETSI TS 102 778-1: " Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic
Signature Profiles; Part 1: PAdES Overview - a framework document for PAdES".
NOTE: The above standard is composed of multiple parts and implementation of the framework may require
implementation of requirements stated in other parts of the standard.
[7] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
[8] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a
Community framework for electronic signatures.
[9] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on
electronic identification and trust services for electronic transactions in the internal market and
repealing Directive 1999/93/EC.
[10] ISO/IEC 15408-2: "Information technology - Security techniques - Evaluation Criteria for IT
security - Part 2: Security functional components".
[11] ETSI TS 102 165-2: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Methods and protocols; Part 2: Protocol Framework Definition;
Security Counter Measures".
[12] ISO/IEC ISO/IEC 10181-2: "Information technology - Open Systems Interconnection - Security
frameworks for open systems: Authentication framework - Part 2".
[13] ETSI EN 319 142: "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures".
[14] ETSI EN 319 132: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TS 103 436 V1.1.1 (2016-08)
[15] ETSI EN 319 122: "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures".
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 TR 103 087: "Reconfigurable Radio Systems (RRS); Security related use cases and threats in
Reconfigurable Radio Systems".
[i.2] BlueKrypt: Cryptographic Key Length Recommendation.
NOTE: Available at http://www.keylength.com.
[i.3] ETSI TS 102 165-1: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Methods and protocols; Part 1: Method and proforma for
Threat, Risk, Vulnerability Analysis".
[i.4] ISO/IEC 10181-4:1997: "Information technology - Open Systems Interconnection - Security
frameworks for open systems: Non-repudiation framework - Part 4".
[i.5] Shannon, Claude E. (July/October 1948). "A Mathematical Theory of Communication". Bell
System Technical Journal 27 (3): 379-423.
[i.6] Marcelo A. Montemurro, Damián H. Zanette: "Universal Entropy of Word Ordering Across
Linguistic Families".
NOTE: Available at http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3094390/ as PMCID: PMC3094390.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI TR 103 087 [i.1] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TR 103 087 [i.1] and the following apply:
DoS Denial of Service
DDoS Distributed Denial of Service
IMEI International Mobile Equipment Identity
IMSI International Mobile Subscriber Identity
OSI Open System for Interconnection
PKC Public Key Certificate
PKI Public Key Infrastructure
PMCID PubMed Central reference number
TSF ToE Security Functions
TTP Trusted Third Party
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TS 103 436 V1.1.1 (2016-08)
4 Review of objectives and high level requirements
The objectives stated in ETSI TR 103 087 [i.1] are copied in table 1 and classified in terms of the form of security
function that is required to meet the objective. In addressing each objective the form of countermeasure required is
discussed in some detail and the overall class or strategy of countermeasure is indicated.
Table 1: Review of security objectives
Id Text of objective Countermeasure Strategy
1 The RRS platform should provide means to Encryption of content (it is assumed Confidentiality
ensure that the content of communication that the link is open (radio broadcast)
between the application store and the RE are and that the adversary is able to
rd
protected from exposure to unauthorised 3 eavesdrop/intercept the content).
parties (see note 1)
2 The RRS should provide means to verify that the Integrity check sum added to content. Integrity
content of communication between the
application store and RE has not been
manipulated prior to processing at receipt (see
note 1)
3 The RRS platform should provide means for the The RE shall have a unique application Authentication and
application store to verify the identity of the RE store access identity that is bound to a Identity
(see note 2) set of credentials shared between the Management
application store and the RE. The
identity may be selected by the user of
the RE (open market scenario) or may
be defined by the RE manufacturer
(closed market scenario).
4 The RRS platform should provide means for the The application store shall have an Authentication and
RE to verify the identity of the application store unique name that is tied to its attribute Identity
(see note 3) as an application store for RRS in the Management
form of a public key certificate with an
attribute extension when operating in
an open environment but if operating in
a closed environment may allow for
authentication using a conventional
challenge response protocol in a
shared secret mode
5 The RRS platform should provide means to It is possible to limit the entities Access Control,
detect and prevent denial of access to the allowed to offer traffic to the network Network Topology
communications channel between the through an access control policy. In
application store and the RE addition DoS (and DDoS) attacks may
be mitigated by using resilient and
redundant network paths (i.e.
mitigation by network topology design)
6 The RRS platform should provide means to The originator of the RAP shall create Integrity
verify that the RAP has not been modified a signed hash of the RAP, and supply
between having been made available by the the signature with the attribute
RAP originator and having been downloaded on certificate of the RAP allowing
the RE verification of the hash and signature
by the receiving party using the
contained public key
7 The RRS platform should provide means for the As above where the RAP has been Authentication and
RE to verify the source of the content supplied signed by the originator verification of Identity
via the Radio application store the signature shall result in proof of the Management
source of the RAP
rd
8 The RRS platform should provide means to Proof may be lodged with a trusted 3 Non-repudiation
prevent the application store denying provision party or may be maintained locally
of an application to the RE within a secure enclave of the device.
9 The RRS platform should provide means to As such every transaction between the
application store and the RE shall be
prevent the RE denying receipt of an RA from
the Radio application store securely logged in such a way that the
logs cannot be tampered with by an
10 The RRS platform should provide means to
unauthorized entity
prevent the RE denying installation of an RA
from the Radio application store
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TS 103 436 V1.1.1 (2016-08)
Id Text of objective Countermeasure Strategy
11 The RRS framework should ensure measures Testing and distribution network should Liability framework
are provided to prevent installation of malicious verify, as far as reasonable, the
RAPs (see note 4) functionality of every RAP
12 The RRS framework should ensure measures Run time attestation of integrity Attestation
are provided to prevent modification of an RAP
after installation (see note 5)
13 The RRS framework should provide means to Cryptographically strong document Digital signature
verify the legitimacy of the Declaration of signature verification.
Conformity (DoC) and CE marking (see note 6) Maintenance and distribution of PKI
blacklist of invalid DoC identities
Online verification of signature of DoC PKI
14 The RRS platform should provide means to be The DoC should be identifiable using a Identity
able to uniquely identify the master copy of the URI or equivalent management
DoC (see note 7)
Master copy should be named Digital signature
distinctly from any copy and signed as
such. In addition copies should be
signed/verifiable as legitimate copies
and point (URI/URL) to the master
copy
15 Where CE marking and DoC are provided for This requires the hardware to have Hardware tamper
display of the radio equipment by means of user tamper-resistant storage to hold the resistance
interaction the RRS platform should provide DoC/CE data
means to assure that the marking is resistant to
tampering (see note 8)
16 The RRS platform should provide means to
The manifest of required platform Integrity
validate data used to describe the installation capability should be covered in the
requirements of the RAP (the RAP metadata) signature and integrity check function
against the capabilities of the RE and prohibit
installations where a mismatch is identified
17 The RRS platform should prevent an Authentication of parties Access Control,
unauthorised third-party from determining that Identity
the DoC is being updated Management
18 The RRS platform should prevent an Encryption of signalling Confidentiality
unauthorised third-party from determining that
the complete DoC is being retrieved from a
simplified DoC over the network
19 The RRS platform should provide means to Authenticated access control combined Integrity
prevent modification of the DoC apart from with change management control of
installation and update, in particular at rest the DoC
20 When the DoC is being updated, or the complete The integrity measure here applies to Integrity
DoC is being retrieved, the RRS platform should data in transit and may be applied at
allow integrity protection of said DoC while it is the transport entity as opposed to the
in-transit between the relevant entities in the document level
network and components on the device
21 The RRS platform should prevent an The DoC should always be available in Access Control,
unauthorised third-party to delete, install or read-only form on the RE but Authentication,
rd
otherwise alter a DoC on the RE (see note 9) authorized 3 parties shall be allowed Identity
to update the DoC. This may happen Management
as a result of installation of a new RAP
that requires modification of the stored
DoC to support any new capability
offered by the RAP
22 When there is only a digital DoC and no paper This requires the hardware to have Hardware tamper
DoC provided with the RE, the RRS platform tamper-resistant storage to hold the resistance
should provide means towards tamper- DoC/CE data
resistance of the DoC at rest on the RE
23 When the complete DoC is requested over the The checksum for proof of integrity Integrity
network based on a simplified DoC residing on shall be measured across the set of
the RE, the RRS platform should provide means elements that compose the DoC
towards the availability of complete DoC to the
RE
24 When the DoC is being updated, or the complete Authentication of parties Access Control
DoC is being retrieved, the RRS platform should
allow for identification and authentication of
relevant entities in the network and components
on the device
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TS 103 436 V1.1.1 (2016-08)
Id Text of objective Countermeasure Strategy
25 The RRS platform should allow for The attribute signature of the DoC shall Identity
authentication of content (DoC) to the relevant identify by model type the components management
component on the device of the RE that it applies to and this set
of data authenticated in the DoC's
signature
26 When there is only a digital DoC and no paper No technical capability required, Liability framework
DoC provided with the RE, the system should however all digital signatures of
implement measure to ensure that the digital documents shall be developed in line
DoC provides at least the same level of with the operational framework of the
confidence as the DoC in Paper form Digital Signature Directive [8] and the
eIDas Directive that will supercede it
[9]
27 The RRS platform should allow for the A framework of non-repudiation of Non-repudiation
traceability of devices that have received an origin, and of receipt shall be provided
updated DoC
28 The RRS platform system should provide means
to prove reception and installation of a DoC by a
device
29 The RRS platform should allow for binding the The attribute signature of the DoC shall Secure storage
DoC to the device that receives it identify by model type the components
of the RE that it ap
...