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

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

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.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

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
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
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
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
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
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
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
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
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 applies to and this set
of data shall be authenticated in the
DoC's signature and thus bind the DoC
to the device. Additionally the RE serial
number shall be used as a nonce
when storing the DoC in a secure
enclave of the RE
30 The RRS platform should allow for verifying that At installation the serial number of the Local and Remote
the presented DoC is bound to the device RE shall be used as a nonce in the attestation
secure storage of the DoC, thus only if
the DoC can be retrieved using the
serial number of the RE as a key
NOTE 1: The means of providing the checksum is to some extent dependent on the nature of the content. In the
application store environment the checksum should form part of the digital signature of the content itself.
However it may be reasonable to add integrity verification to the transmission path itself, for example
mandating IPsec in ESP mode with a valid ICV field (and avoiding use of the NULL algorithm of course), or
mandating the use of TLS [7] with authentication, integrity and encryption enabled.
NOTE 2: In conventional systems such as in 2G/3G cellular networks the radio equipment is identified by the
International Mobile Equipment Identifier (IMEI) and the subscriber by the International Mobile Subscriber
Identity (IMSI). In some systems the radio equipment is identified by its MAC address (at Layer 2 of the OSI
stack). In the wider ICT domain equipment is often identified by its serial number. The identity to be verified
for the RE has to be immutable and bound to a credential for its authentication.
NOTE 3: The commercial architecture of application stores may influence the design in this case. In the short term it
is assumed that a single RE will be associated with a single application store.
NOTE 4: This is a problematic area as it cannot be done with fixed tests as the attacker will craft code to pass such
tests whilst remaining malicious. The role of fuzzing and such like may be integrated but such non-
deterministic tests are not always valid either. The end result is that the liable party should be clearly
identifiable for the correct operation of the RAP.
NOTE 5: This is an area of study in the ISG NFV domain and as such is of direct relevance in RRS. The aim in the
NFV work is to prevent installation of a compromised image. It is strongly recommended to harmonise the
activity in the ISG NFV and RRS for standardized solutions.
NOTE 6: The Public Key Infrastructure is an almost essential support to the signature scheme used to verify identity
and attributes that are asserted using the certificates and associated signatures. In addition a liability
framework should be instantiated that clearly identifies the roles of each actor/stakeholder and the penalties
that apply for transgressions. The liability framework should be based on the existing market controls with
due consideration of the role of stakeholders such as RAP providers that may not have been previously
considered.
NOTE 7: For the DoC each copy shall be marked in such a way that it is clear if it is the master, a copy, or an element
of a DoC and also marked in this case as either master or copy. It should be clear to the reader of the DoC
where it has been generated, by whom and for which equipment (or combination of equipment).
NOTE 8: The mutability of an RE in RRS requires that the DoC/CE data held on the device is also mutable unless the
DoC is always stored externally to the device.
NOTE 9: For any implementation not implementing hardware based tamper resistance, an equivalent means of
providing persistent storage even if the device operating system is corrupted is required.

ETSI
11 ETSI TS 103 436 V1.1.1 (2016-08)
Where digital signature is to be deployed there is a risk from advances in computing that may make the more common
approaches invalid. Both the RSA and ECC approaches are vulnerable to Shor's and Grover's algorithms when run on a
quantum computer that will break the algorithms (i.e. given knowledge of the public key certificate the private key can
be found in polynomial time). The alternative for future proof digital signature is to use an approach that is considered
Quantum-safe, i.e. an algorithm that is not weakened by the capabilities of a quantum computing attack. Within ETSI
the impact of quantum computing is being addressed in 2 groups: ISG Quantum Safe Cryptography (QSC) with a role
to identify cryptographic primitives that will be viable for reference in standards; CYBER with a role to identify
business continuity requirements in transition to quantum safe cryptography. In addition it is noted that Grover's
algorithm reduces the effective strength of symmetric cryptography in such a way that the key length has to be doubled
to retain the same level of cryptographic strength (i.e. a system running with 128 bit keys to give 128 bit security will
need to run with 256 bit keys to retain 128 bit security in the presence of Grover's algorithm). It is also noted that some
cryptographic modes for symmetric key encryption are rendered null for some quantum attacks and such attacks need to
be considered for systems with long key life.
5 Countermeasure framework
5.1 Notes for interpretation
NOTE 1: The convention used in the present document is to refer to the thing being protected as a document even if
in practice it may be an executable program, or a configuration file or something else.
NOTE 2: The convention of referring to the legitimate parties to a transaction or involved in a security association
as Alice and Bob, with the adversary referred to as Eve is followed in the text below.
NOTE 3: Where digital signature is to be deployed there is a risk from advances in computing that may make the
more common approaches invalid. Both the RSA and ECC approaches are vulnerable to Shor's and
Grover's algorithms when run on a quantum computer that will break the algorithms (i.e. given
knowledge of the public key certificate the private key can be found in polynomial time). The alternative
for future proof digital signature is to use an approach that is considered Quantum-safe, i.e. an algorithm
that is not weakened by the capabilities of a quantum computing attack. The recommendations given in
this clause take account of the requirement for cryptographic agility that is necessary to address this
specific class of threats.
NOTE 4: The framework for the countermeasures identified has been expanded from the templates given in ETSI
TS 102 165-2 [11].
5.2 Identity management and authentication
The following entities shall be named and authenticated in the process of RAP and DoC Distribution, Development and
regulatory compliance.
• Developer of RAP - identified by an identity form of Public Key Certificate (PKC) according to
Recommendation ITU-T X.509 [5].
• Application store - identified by an attribute form of PKC according to Recommendation ITU-T X.509 [5]
NOTE: The attribute form of certificate extends the public key certificate but does not contain the public key
which is contained in the tied PKC.
• RE Manufacturer - identified by both an identity form, and by an attribute form, of PKC according to
Recommendation ITU-T X.509 [5] where attribute is of type RRS_RE_MANUFACTURER.
The primary purpose of the authentication service is to counter masquerade attacks with a secondary purpose of
verifying identity for a number of accountability services, the latter mainly in the context for RRS of non-repudiation
and to verify assertions of ownership and access rights. The authentication framework for RRS is derived from
ISO/IEC 10181-2 [12].
ETSI
12 ETSI TS 103 436 V1.1.1 (2016-08)
There are a number of ways of achieving authentication where for each specialization the countermeasure remains
constant: to give assurance that Bob is really Bob and not Alice (i.e. to counter masquerade). An example of the
specialization hierarchy for authentication is shown in figure 1.
cd Authentication tree
Authentication
ChallengeResponse MessageAuthenticationCode DigitalSignature
PasswordCR
CryptoCR
Figure 1: Authentication countermeasure specializations
Whilst challenge response protocols may be based on a username-password combination this is categorized as weak
(see annex on strong passwords) and is not considered further in the present document (see also annex B).
5.3 Document integrity proof and verification
5.3.1 Overview of process
The developer of the RAP shall provide proof of the integrity of the package. The proof of integrity shall be provided
by digital signature of the entire package (commonly referred to as document) to be delivered. Most commonly this is
achieved by encrypting the cryptographic hash of the document using the private key of the signer and distributing the
signed hash with the public key of the signer and the document.
The process extends that used for general distribution of Java Midlets and is summarized in figure 1 for application in
RRS.
ETSI
13 ETSI TS 103 436 V1.1.1 (2016-08)

Figure 2: Simplified distribution of signed RAP
The software developer of a RAP shall distribute software as a signed data object in the context of an Recommendation
ITU-T X.509 [5] digital signature. The software to be distributed shall be identified as of type RRS-RAP using the
Object IDentifier (OID):
• itu-t(0) identified-organization(4) etsi(0) ts-103-346 (3346) rrs-rap (0)
NOTE: The ASN.1 OID is defined within the ETSI deliverable branch of the OID tree.
5.4 Non-repudiation framework
5.4.1 Overview of non-repudiation
ISO/IEC 10181-4 [i.4] states:"The goal of the Non-repudiation service is to collect, maintain, make available and
validate irrefutable evidence concerning a claimed event or action in order to solve disputes about the occurrence of
the event or action".
A Non-repudiation service may be considered as a suite of discrete facilities that when considered in a process generate
a non-repudiation service. Each discrete facility may be considered using a "use-case" in UML (see figure 3).
ETSI
14 ETSI TS 103 436 V1.1.1 (2016-08)

Figure 3: Simplified architecture of use of non-repudiation facilities in NGN
Using ISO/IEC 10181-4 [i.4] as a framework the non-repudiation service involves the generation, verification and
recording of evidence, and the subsequent retrieval and re-verification of this evidence in order to resolve disputes.
Disputes cannot be resolved unless the evidence has been previously recorded.
The purpose of the Non-repudiation service described in this framework is to provide evidence about a particular event
or action, in particular the installation of a RAP and the distribution of RAP. Non-repudiation services may be requested
by entities other than those directly involved in the event or action, an example for RRS may be the carrying out of
regulatory market surveillance and the requirement of proof that the RAP is identified in the DoC and has been installed
from a legitimate source.
When messages are involved, to provide proof of origin, the identity of the originator and the integrity of the data shall
be able to be confirmed by examination of the appropriate evidence. To provide proof of delivery, the identity of the
recipient, and the integrity of the data shall be able to be confirmed by examination of the appropriate evidence. In some
cases, evidence concerning the context (e.g. date, time, location of the originator/recipient) may also be required.
5.4.2 Stage 1 model for non-repudiation
5.4.2.1 Procedures
5.4.2.1.1 Provision/withdrawal
Non-repudiation shall always be be available.
5.4.2.1.2 Normal procedures
5.4.2.1.2.1 Activation/deactivation/registration/interrogation
Non-repudiation shall always be activated. Non-repudiation shall not be de-activated.
NOTE: These terms are difficult to address as non-repudiation is a composed countermeasure (see clause 5.4.2.2)
and requires its composite elements to be activated and de-activated.
ETSI
15 ETSI TS 103 436 V1.1.1 (2016-08)
5.4.2.1.2.2 Invocation and operation
Non-repudiation is a composed countermeasure, this means that it requires other countermeasures including identity
management, authentication, integrity (the latter two may be combined in digital signature). The invocation and
operation procedures of the other countermeasures are defined in the present document.
5.4.2.1.3 Exceptional procedures
5.4.2.1.3.1 Activation/deactivation/registration/interrogation
Not applicable.
5.4.2.1.3.2 Invocation and operation
Non-repudiation is a composed countermeasure. The exceptional invocation and operation procedures of the other
countermeasures defined in the present document apply in clause 5.
5.4.2.2 Interactions with other security services
In ISO/IEC 10181-4 [i.4] there is a description of how other security services can be used to support non-repudiation.
The bulleted list below indicates the relationship between the services.
• Authentication:
- When entities interact with a TTP they may be required to prove their identity using an authentication
service.
• Access control:
- An access control service may be used to ensure that information stored by a TTP, or service offered by a
TTP, is made available only to authorized users.
• Confidentiality:
- Confidentiality services may be required to protect the data from unauthorized disclosure and also to
protect against unauthorized disclosure of evidence.
• Integrity:
- As the non-repudiation service relies upon proof of particular data either being sent (proof of delivery) or
received (proof of receipt) it is imperative that the data item can be shown to be maintained in a known
and consistent state which may require the use of integrity services as described elsewhere in the present
document.
• Key management:
- As a non-repudiation service may be cryptographically ensured it is required that the set of keys used in
the service is properly managed. There is a description of key management elsewhere in the present
document.
6 Information flows and reference points (stage 2)
6.1 Overview
The stage 2 information flows and reference points are extracted from the use case model given in ETSI
TR 103 087 [i.1] copied in figure 4.
ETSI
16 ETSI TS 103 436 V1.1.1 (2016-08)

Figure 4: Use cases and actors for RRS application deployment from ETSI TR 103 087 [i.1]
As identified in ETSI TR 103 087 [i.1] the following actors exist in the distribution of RAP:
• Developer
• Rogue developer
• RE Manufacturer
• DoC responsible party
• Regulator
• Application store
• Root
...