armour experiments and requirements€¦ · iot [7], gsma [13]). based on the analysis of the...

Deliverable D1.1

ARMOUR Experiments and Requirements

Version Version 1.0

Lead Partner Easy Global Market

Date 25/05/2016

Project Name ARMOUR – Large-Scale Experiments of IoT Security Trust

Ref. Ares(2016)2451302 - 26/05/2016

2

Call Identifier H2020-ICT-2015

Topic ICT-12-2015 Integrating experiments and facilities in FIRE+

Project Reference 688237

Type of Action RIA – Research and Innovation Action

Start date of the project February 1st, 2016

Duration 24 Months

Dissemination Level X PU Public CO Confidential, restricted under conditions set out in Model Grant Agreement CI Classified, information as referred to in Commission Decision 2001/844/EC

Abstract D1.1 “ARMOUR Experiments and Requirements” sets the scene for project ARMOUR, listing the IoT security experiments to be conducted within the project, highlighting the security vulnerabilities they plan to address and identifying their requirements, in relation to their set-up, monitoring and results collection and analysis.

Disclaimer This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 688237, but this document only reflects the consortium’s view. The European Commission is not responsible for any use that may be made of the information it contains.

3

Revision History

Revision Date Description Organisation

0.1 11/04/2016 Creating document EGM, SMA, ODINS

0.4 15/04/2016 Including initial contributions SMA, ODINS, UI, SYN, EGM

0.5 29/04/2016 Merging of contribution received following the 18-19/04/2016 meeting EGM, SYN

0.6 03/05/2016 Including contributions 3.1.3 (SMA) and 3.2 (JRC) and revision on 4.2.1 (ODINS)

SMA, JRC, ODINS, EGM

0.8 11/05/2016

Introducing revision from UI and INRIA. Aggregated analysis of requirements and vulnerability patterns is made

INRIA, UI, EGM

0.9 20/05/2016 Completion of the document SMA, UI, INRIA, SYN, EGM

1.0 25/05/2016 Proof-reading and minor corrections SYN, UPMC

4

Table of Contents 1 Executive summary ........................................................................................................ 6

2 Introduction .................................................................................................................... 8

2.1 Purpose ................................................................................................................... 8

2.2 Methodology ............................................................................................................ 9

2.2.1 Security vulnerabilities and experiments classification ...................................... 9

2.2.2 Requirements collection .................................................................................. 10

3 ARMOUR security reference framework ...................................................................... 12

3.1 Relevant security frameworks ................................................................................ 12

3.1.1 OWASP IoT ..................................................................................................... 12

3.1.2 oneM2M .......................................................................................................... 14

3.1.3 GSMA IoT Security guidelines ........................................................................ 17

3.2 Need of a reference framework for certification & labelling .................................... 18

3.3 ARMOUR security framework ................................................................................ 21

4 Experiments description and requirements .................................................................. 22

4.1 Introduction ............................................................................................................ 22

4.2 Experiments description ........................................................................................ 22

4.2.1 EXP1: Bootstrapping and group sharing procedures ...................................... 22

4.2.2 EXP2: Sensor node code hashing .................................................................. 29

4.2.3 EXP3: Secured bootstrapping/join for the IoT ................................................. 37

4.2.4 EXP4: Secured OS / Over the air updates ...................................................... 41

4.2.5 EXP5: Trust aware wireless sensors networks routing ................................... 43

4.2.6 EXP6: Secure IoT Service Discovery .............................................................. 46

4.2.7 EXP 7: Secure IoT platforms ........................................................................... 49

5 Security analysis .......................................................................................................... 53

6 Requirements analysis ................................................................................................. 55

7 Conclusion ................................................................................................................... 57

5

8 Annexes ....................................................................................................................... 58

8.1 References ............................................................................................................ 58

8.2 Vulnerability patterns ............................................................................................. 59

8.3 oneM2M security requirements analysis ................................................................ 66

6

1 Executive summary

Security, Privacy and Trust are critical elements of the IoT landscape where inadequacy of these is a barrier to the deployment of IoT systems and to broad adoption of IoT technologies. The ARMOUR project is aiming at providing duly tested, benchmarked and certified Security & Trust technological solutions for large-scale IoT using upgraded FIRE IoT/Cloud testbeds properly-equipped with software tools for executing Security & Trust experimentations.

This deliverable is setting the scene for the entire project. It defines a common language and ontology to express and share project activities. This includes primarily a list of vulnerabilities of IoT systems that will be addressed within the project, selected from the analysis of on-going IoT related security initiatives (NIST [14], oneM2M [23], OWASP IoT [7], GSMA [13]). Based on the analysis of the proposed security experiments, ARMOUR defines four segments of an IoT deployment:

1. Devices and data, 2. (Wireless) connectivity, 3. Platforms and 4. Applications and Services.

The ARMOUR security framework defines the security in terms of availability, integrity and confidentiality/privacy, offering solutions and guidelines for each of the aforementioned four segments and the respective identified elements to be secured.

Figure 1 ARMOUR Security Framework

The ARMOUR security framework takes as its main entry the oneM2M vulnerabilities, threats and risk assessment methodology and identifies eventually missing vulnerabilities and threats based on the seven experiments to be conducted within the project. The list of retained ARMOUR vulnerability patterns is provided in section 8.2. In addition, an analysis

7

of the relevant options for IoT security labelling is provided and the overall workflow for labelling, including testing activities is explained.

The seven experiments planned in the project and covering the four listed segments, are:

• EXP 1. Bootstrapping and group sharing procedures • EXP 2. Sensor node code hashing • EXP 3. Secured bootstrapping/join for the IoT • EXP 4. Secured OS / Over the air updates • EXP 5. Trust aware wireless sensors networks routing • EXP 6. Secure IoT Service Discovery • EXP 7. Secure IoT platform

For each experiment, a process is applied in order to identify the vulnerabilities to be addressed by the experiment and the solutions to be experimented over the ARMOUR testbed to mitigate these vulnerabilities. Related requirements needed in order to properly setup the experimentation (such as software tools, hardware platforms, network connectivity, etc.) have been identified and aggregated into a comprehensive list of 30 general requirements.

8

2 Introduction

2.1 Purpose

The Internet-of-Things (IoT) is rapidly heading for large scale; meaning that all mechanisms and features for the future IoT need to be especially designed and duly tested/certified for large-scale deployments. Also, Security, Privacy and Trust are critical elements of the IoT where inadequacy of these is a barrier to the deployment of IoT systems and to broad adoption of IoT technologies. Suitable duly tested solutions are then needed to cope with security, privacy and safety in the large scale IoT. Interestingly, world-class European research on IoT Security & Trust is growing in European companies (especially SME) and academia where innovative algorithms and technologies have been proven to work adequately in the lab and/or even in small-scale pilots. Moreover, unique experimental IoT facilities exist in the EU FIRE initiative [1] that make possible large-scale, experimentally-driven research. However, these facilities are not yet fully equipped to support IoT Security & Trust experiments. Europe is a leader in IoT Security & Trust testing solutions (e.g. RASEN toolbox [2], ETSI Security TC, etc.) that can be extended to large-scale testing environments and be integrated in FIRE IoT testbeds for supporting experimentations. The ARMOUR project is aimed at providing duly tested, benchmarked and certified Security & Trust technological solutions for large-scale IoT using upgraded FIRE large-scale IoT/Cloud testbeds properly-equipped for Security & Trust experimentations. In this perspective, ARMOUR:

1. Enhances two outstanding FIRE testbeds (>2700nodes; ~500users) with the ARMOUR experimentation toolbox for enabling large-scale IoT Security & Trust experiments;

2. Delivers seven properly experimented, suitably validated and duly benchmarked methods and technologies for enabling Security & Trust in the large-scale IoT;

3. Define a framework to support the design of Secure & Trusted IoT applications as well as establishing a certification scheme for setting confidence on Security & Trust IoT solutions directly targeting European market needs.

For that purpose, the project has been organised in 2 phases, cutting across several workpackages (Figure 2). The first phase deals with the experiments preparation and functional enhancement of the FIT IoT-LAB testbed [3] for supporting large-scale IoT security & trust experimentations and the development of methodologies, whereas phase 2 is focusing on the execution, assessment and benchmarking of the selected experiments, the adaptation of the FIESTA testbed for handling ARMOUR experimentation data and benchmarks, the study and certification of large-scale IoT security & trust applications/solutions and finally assorted optimisations and improvements.

9

Figure 2: ARMOUR project organisation

Four Workpackages are at the core of technical activities:

1. Work Package 1 deals with (at Phase 1) the definition of the ARMOUR experiments, the establishment of the experimentation approach and methodology and the preparation of the experimentation phase and (at Phase 2) with the actual execution, assessment and benchmarking of the experiments also including reporting on them.

2. Work Package 2 relates to (in Phase 1) the creation of the novel and unique ARMOUR large-scale Security & Trust testing framework and (in Phase 2) the final testing, optimisation and improvements to the framework.

3. Work Package 3 is about (during Phase 1) the detailed analysis of the target FIRE testbeds, definition of guidelines for integration of ARMOUR in IoT deployments/testbeds and the actual integration of the ARMOUR testing framework (developed in WP2) with the IoT-LAB testbed; and (during Phase 2) the adaptation of the FIESTA testbed for ARMOUR, and the optimisation of the IoT-LAB integration, finalisation of integration testing and any required optimisations/improvements set during experiments execution stage.

4. Work Package 4 develops (in Phase 1) the ARMOUR benchmarking methodology and the framework to design large-scale IoT secure & trusted applications, and (in Phase 2) the study of several key application domains for IoT security & trust and the creation of the certification/labelling scheme for large scale security & trust technologies.

In that context, the deliverable D1.1 “Experiments and Requirements” aims at refining the identification and definition of ARMOUR experiments and elicits the related requirements.

2.2 Methodology

2.2.1 Security vulnerabilities and experiments classification This deliverable is setting the scene for the entire project. It is thus important that it defines a common language and ontology to express and share project activities. This encompasses first the need to identify and classify vulnerabilities patterns of IoT systems.

10

Identifying security vulnerabilities is a common approach in IT systems and it has been decided within the project to build, as much as possible, on existing frameworks and adapt them to the specificities of ARMOUR IoT experimentation. Inspiration has thus been taken from the CVE (Common Vulnerabilities and Exposure) framework which provides a dictionary of publicly known information security vulnerabilities and exposures [4].

A vulnerability pattern intends to describe vulnerabilities, their conditions of occurrence and impacts. The following table has been proposed to describe these vulnerability patterns.

TITLE Id Vulnerability pattern summary

1 line description

Vulnerability pattern description

Add additional, more technical details as needed

Applicable systems/devices /platforms

Indicate the part of the system which are subject to the attack

Timing of introduction

Describe the timing at which the attack takes place

Consequences Describe the effects of the attack when successful Example Optional Relationships Relations to other vulnerabilities

Table 1: Vulnerability pattern description template.

2.2.2 Requirements collection A second objective of that report is to identify the general requirements of the experiments in relation with security testing. For that purpose, the IETF RFM2119 [5] has been decided to be used in order to detail these requirements in an unambiguous way by expressing them in natural language by making use of standardised approaches and vocabularies. Firstly, priorities will be given among requirements through the use of the following words:

• MUST – This word, or the terms “REQUIRED” or “SHALL”, means that the definition is an absolute requirement of the specification.

• MUST NOT – This phrase, or the phrase “SHALL NOT”, means that the definition is an absolute prohibition of the specification.

• SHOULD – This word, or the adjective “RECOMMENDED”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

• SHOULD NOT – This phrase, or the phrase “NOT RECOMMENDED” means that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.

• MAY – This word, or the adjective “OPTIONAL,” means that an item is truly discretionary.

• FUTURE – This word means that objectives are provided as guidance or expectation and may or may not be accurate.

Figure 3: Requirements levels [5].

Requirements are then expressed based on the following sentence template, as suggested by IREB (Figure 4).

11

Figure 4: Requirements description template [6].

Finally, a typology of requirements is proposed in order to classify them in a common way. The proposed typology is as follows:

• Infrastructure requirements: related to the infrastructure/testbed hosting the experiment and related needed resources.

• Set-up requirements: related to the set-up and configuration of the experiment

• Control requirements: related to the control of the experiment such as OTA updates, sniffing devices, etc.

• Analysis requirements: related to the analysis of experiment results with regards to reproducibility, proof of adequate vulnerability mitigation, etc.

For that purpose, each experiment provider has been asked to identify their experimentation requirements based on the methodology described above. These requirements are provided for each experiment and a synthesis is provided and discussed within section 6.

12

3 ARMOUR security reference framework

This section defines the security reference framework for ARMOUR experiments. Since several security frameworks exist, ARMOUR consortium, based on their experience and relevance to the IoT technology, decided to follow OWASP IoT, GSMA and oneM2M frameworks.

Section 3.1 summarizes the three security frameworks relevant to IoT, namely OWASP IoT, oneM2M and GSMA. Section 3.2 introduces the needs of a reference framework for certification and labelling. Section 3.3 describes the ARMOUR security framework that completes and makes reference to existing frameworks, as a first step towards defining a framework towards IoT Security Certification and Labelling.

3.1 Relevant security frameworks

3.1.1 OWASP IoT The OWASP IoT project defines a security framework that gathers information on security issues associated to the IoT development, deployment or technology assessment. It is aiming to help manufacturers, developers as well as consumers to increase their confidence into this rapidly evolving domain.

More specifically, the OWASP IoT security framework defines the following 17 surface areas [7] that may undergo attacks going from device memory to vendor backend APIs through the ecosystem access control and communication, as depicted in Figure 5.

Figure 5: OWASP IoT Surface Areas

Furthermore, they provide ten high level vulnerabilities, synthetized in Table 2 that can be identified among the IoT surface areas.

13

ID Name Description I1 Insecure Web Interface Anyone having access to the web interface

if the system is not secured enough could perform attacks such as SQL Injection or XSS (for more details see OWASP TOP 10).

I2 Insufficient Authentication/Authorization

When weak passwords are used or poorly protected. It is prevalent if it is assumed that the interfaces wen connections from external networks are not taken into account.

I3 Insecure Network Services They might be susceptible to buffer overflows, or attacks that create denial of service.

I4 Lack of Transport Encryption/Integrity Verification

Allows data to be viewed as it travels over local networks or internet. Often local network is under such risk as it is assumed that will not be widely visible.

I5 Privacy Concerns Lack of proper protection of collected personal data

I6 Insecure Cloud Interface Lack of credentials reset mechanisms or not using SSL for connection on the cloud interface

I7 Insecure Mobile Interface Lack of credentials reset mechanisms or not using SSL for connection to the mobile wireless network

I8 Insufficient Security Configurability

Lack of granularity in configuration options, especially for user permissions

I9 Insecure Software/Firmware They contain hard coded sensitive data or unprotected network connection for updates of the software/firmware

I10 Poor Physical Security USB or other ports can be easily accessed on the device for instance to bypass configurations or permissions.

Table 2: OWASP IoT Top Ten Vulnerabilities [8]

For each vulnerability, among other elements, a short description is given, linking it to the problem that creates the vulnerability, the threats, attack vectors and their impact (technical or business). A risk analysis based on the OWASP Threat Risk Modelling [9] and Risk Rating Methodology [10] is also performed for each of the vulnerability categories. In Figure 6 we present an example of OWASP IoT vulnerability, for instance the first one I1: Insecure Web Interface.

14

Figure 6: OWASP IoTI1: Insecure Web Interface

In addition, in order to verify the application resilience to such attacks, the framework provides countermeasures, as well as attack scenarios for each of the ten vulnerabilities, as depicted on the bottom of Figure 6. The framework makes reference to existing vulnerabilities in the world-wide known vulnerabilities databases, such as CWE.

To resume, the OWASP IoT security framework indeed offers guidance for security awareness and testing. Hence, it often remains too high level and lacks specific methodology that could be used in a systemic way - for instance in security audits. Moreover, the attack surface areas need more structured view - for instance based on the 4 segments of IoT: devices and data, (wireless) connectivity, platforms, and applications and services.

3.1.2 oneM2M oneM2M was established to develop a single horizontal platform for the exchange and sharing of M2M/IoT data among all applications. oneM2M is creating a distributed software layer which provides a framework for interworking with different technologies [11].

oneM2M defines a security framework from its own architecture model [12] which supports end-to-end M2M services. A high level functional view of this architecture model is shown in Figure 7. Starting from this, oneM2M identifies four security domains. Each of these domains provides a set of security measures to address certain threats that may appear on it:

15

Figure 7: oneM2M context and security domains

• Application domain security: A set of security measures that enable the Application entity and the Common Services entity to securely exchange messages and protect against attacks on (1).

• Intra Common Services domain security: A set of security measures that enable Common Services Functions in the Common Services entity to securely exchange messages and protect against attacks on (2).

• Inter Common Services domain security: A set of security measures that enable messages secure exchange between different Common Services entities and protect against attacks on (3).

• Underlying Network security: A set of security measures that enable the Common Services entity and the Underlying Network Services entity to securely exchange messages and protect against attacks on (4).

In addition, the oneM2M security architecture consists of the following layers:

• Security Functions layer: this layer contains a set of security functions which can be classified into six categories; they are Identification, Authentication, Authorization, Security Association, Sensitive Data Handling and Security Administration.

• Security Environment Abstraction Layer: this layer implements various security capabilities such as key derivation, data encryption/decryption, signature generation/verification, security credential read/write from/to the Secure Environments, and so on. The security functions in the Security Functions Layer invoke these functions in order to do the operations related to the Secure Environments. In addition, this layer also provides physical access to the Secure Environments. This layer is not specified in the oneM2M release 1.

• Secure Environment layer: this layer contains one or multiple secure environments that provide various security services related to sensitive data storage and sensitive function execution. The sensitive data includes SE capability, security keys, local credentials, security policies, identity information, subscription

16

information, and so on. The sensitive functions include data encryption, data decryption, and so on.

The definition of threats that can appear in each domain, as well as the implementation of security measures to solve them or palliate them, are based on the following aspects: secure storage of sensitive data, sensitive functions executing operations on sensitive data and secure connections allowing the secure transmission of sensitive data. Based on them, oneM2M describes a set of vulnerabilities relevant to the security domains explained above. To do this, a predefined template is used that includes the following information: the issue caused by the threat, a description of the vulnerability, the affected security domains and the list of M2M stakeholders and M2M architecture components which are impacted by the threat. Thus, Table 3 shows an example of a vulnerability defined by oneM2M.

Threat ID 1

Overview Long-term service-layer keys are discovered while they are stored in M2M Devices or M2M Gateways and are copied.

Issue Copied long-term service-layer keys may be used to impersonate M2M Devices and/or M2M Gateways.

Description Long-term service-layer keys are stored within the M2M Device or M2M Gateway. Those keys are discovered and copied by unauthorized entities and used for illegitimate purposes. Discovery of stored long term service-layer keys may be achieved e.g. by monitoring internal processes (e.g. by Differential Power Analysis) or by reading the contents of memory of the M2M Device or M2M Gateway (by hardware probing or by use of local management commands).

Impacted Use Cases

All

Affected Security domain

Application domain security; Intra Common Services domain security; Inter Common Services domain security; Underlying Network security, if keys are shared with underlying network.

Affected Stakeholders

M2M Application Service Provider; Manufacturer of M2M Devices and/or M2M Gateways; M2M Device/Gateway Management entities; M2M Service Provider; Network Operator, if network operator keys are shared; User/Consumer

Architecture impact

Device / constrained Device : impacts storage of long-term service-layer keys

Middle Node / Gateway : impacts storage of long-term service-layer keys

Common Services Entity / Function: impacts Security CSF

Table 3: Example of vulnerability defined by oneM2M

Once vulnerabilities have been defined, oneM2M provides a set of countermeasures and solutions to prevent these threats. As before, a predefined template is used that includes the following information: related threats that are solved (or are palliated) by the

17

countermeasure, a description of the countermeasure itself, the affected security domains and a list of advantages and disadvantages of the applicability of such countermeasure. Thus, in Table 4 an example of countermeasure provided by oneM2M is shown.

Related threats Threat 1: Discovery of Long-Term Service-Layer Keys Stored in M2M Devices or M2M Gateways

Threat 2: Deletion of Long-Term Service-Layer Keys stored in M2M Devices or M2M Gateways

Threat 3: Replacement of Long-Term Service-Layer Keys stored in M2M Devices or M2M Gateways

Countermeasure 1 M2M long-term service-layer keys are stored in a HSM (whose tamper-resistance may be certified) residing within the M2M Device / Gateway which renders it infeasible for the attacker to discover the value of keys by logical or physical means.

Applicable Security domain

Application domain security; Intra Common Services domain security; Inter Common Services domain security; Underlying Network security, if keys are shared with underlying network.

Advantages Resists the attack.

A lot of prior art exists in the form of specifications of e.g. ETSI SCP.

Other sensitive data / credentials in addition to long-term service-layer keys can be protected

Disadvantages Additional per-item cost for HSM

Need to specify and demonstrate the level of security assurance across the range of manufacturers and their products.

Table 4: Example of countermeasure provided by oneM2M

To conclude, note that the oneM2M security framework can serve as a starting point for performing risk analysis in M2M scenarios. In addition, countermeasures provided by this framework to address security threats detected during such analysis, can be used as a basis for implementing solutions that prevent them.

3.1.3 GSMA IoT Security guidelines GSMA (GSM Association) provides a set of security guideline documents that as baseline for IoT security issues for all IoT involved entities (service providers, device manufacturers, developers, network operators etc.). These guidelines provide recommendations at three levels: service ecosystem, endpoint ecosystem and network operators, providing also a link to the mobile solution, as one of the most promising connectivity solution for the IoT. Figure 8 shows the GSMA example of an IoT model.

18

Figure 8: GSMA IoT example model.

The GSMA Security Framework does not provide new IoT standards, as oneM2M for instance, but points to currently available solutions, standards and best practices in order to respond to the following IoT security challenges [13]:

To ensure IoT availability, for instance for cellular communication Low-Power Wire Area (LPWA) wireless technology and protocols should be integrated to provide services and solutions for IoT needs i.e. low power consumption and effective communication.

Ensuring identity of IoT ecosystem, means preventing from attacks such as: glitching, side-channel analysis, passive data interception, physical tampering, identify theft. To this end, GSMA proposes to integrate security specifications, for instance oneM2M. These specifications (as detailed in Section 3.1.2 for oneM2M) provide solutions for securing over-the-air firmware updates and management of devices capabilities and identities.

To address the challenge of privacy and security, technologies such as 3G and 4G use mutual authentication to verify the identity of an endpoint and a network. In addition, as the devices are dealing with individual’s personal information, privacy and security needs to be ensured also of this individual information. However, what elements need to be protected are also a key-challenge for IoT service providers as they are often country-dependent (different laws differently even inconsistently implemented in the countries).

In addition, as well as oneM2M, GSMA suggests to follow a concept of information technology risk assessment process. For instance, they refer to the existing process by the National Institute of Standards and Technology Risk Management Framework (NIST) [14] and the Computer Emergency Response Team’s (CERT) OCTAVE model [15].

Although this framework provides guidelines on how to prevent and countermeasures on three levels: service, endpoint and network, is more focused on mobile technology, as one of the most promising technology for working within the “things”.

3.2 Need of a reference framework for certification & labelling

Certification has been defined in various ways in the literature. In this document, we define certification as “a comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security accreditation, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the

19

security requirements for the system”. This definition is extracted from NIST SP 800-37 [20].

The process for certification of a product is generally summed up in four phases:

1. Application. A company applies a product for evaluation to obtain a certification. 2. An evaluation is performed to obtain certification. The evaluation can be mostly

done in three ways: a) the evaluation can be done internally to support self-certification. b) The evaluation can be performed by a testing company, which is legally belonging to the product company. c) It can be third party certification where the company ask a third party company to perform the evaluation of its product.

3. In case of an internal company or a third party company evaluation, the evaluation company provides a decision on the evaluation.

4. Surveillance. It is a periodic check on the product to ensure that the certification is still valid or it requires a new certification.

As described in [19], the initial efforts to define a security testing and certification framework for products produced the Orange book provided criteria for classifying system security into a series of levels – C1, C2, B1, B2, B3 and A1 – depending on how carefully engineered were the mechanisms for assuring the confidentiality of classified information. The Orange book certification became a requirement for ICT systems processing classified information at more than one level. While this was a valuable and needed process to support trust in government systems dealing with secure and sensitive information, the certification process was lengthy and costly. As a consequence, the entry costs were high and certified products lagged behind the commercial state of art (see [19]).

A similar system was set up in Europe, which was called the Information Technology Security Evaluation Criteria (ITSEC), which eventually evolved to the Common Criteria, which is also known as ISO 15408.

In comparison to the Orange book, which was focused on protecting classified information, the Common Criteria is wider and permits systems and devices to be evaluate against a specific protection profile. Common Criteria also defines different levels of evaluation called Evaluation Assurance Levels (EAL) from 1 to 7. In the Common Criteria process, products can be evaluated by competent and independent licensed laboratories so as to determine the fulfilment of particular security properties, to a certain extent or assurance. The protection profile is based on Security Targets, which are the documents, which identify the security properties of the target of evaluation. For more details on the definition of the protection profiles, EAL and other elements of the Common Criteria see [22].

As in the case of the Orange book, the process of evaluation using Common Criteria can be quite expensive and there is an ongoing discussion if some other process could be more suited to the commercial market. A vulnerability based process like the one presented in the ARMOUR project could be more cost effective for the purpose of defining a security certification.

A potential benefit of the evaluation and testing model of the ARMOUR project is to be an alternative to the Common Criteria, which is more cost effective and lean to implement. Instead of a detailed protection profile, ARMOUR defines a formal model of the vulnerabilities and the security properties of the device to be evaluated and generate the

20

test suites automatically from the formal model. In this way, the implementation of the evaluation process can be made more automatic, repeatable and directly linked to the vulnerability or the security properties, which must be supported.

ARMOUR also extends the concept of evaluation levels from Common Criteria to define a labelling scheme. A product, which has been successfully evaluated against a set of vulnerabilities or to support specific security properties, receives an appropriate label. There is a direct relationship between a formal testing model and the related test suite to a specific label. In other words, an IoT device successfully tested against a formal testing model of type A3, will receive the corresponding label A3.

Note that the certification and the related label is only valid for a specific domain where the testing and evaluation took place. The domain defines the environment, the boundary conditions and specific configurations where the evaluation took place. For example, the environment could be specific wireless propagation conditions (urban environment), the boundary conditions could be a limited power supply (e.g., batteries) and the specific configuration can be a setting of the IoT devices (e.g., communication bandwidth or data rate).

The overall workflow is described in Figure 9:

Figure 9: Overall workflow for certification and labelling

In the following sections the ARMOUR security framework will be described, with an identification of the main vulnerabilities. The details on the certification and labelling process are described more in detail in the deliverables of WP4.

21

3.3 ARMOUR security framework

The security framework that we propose in ARMOUR is supposed to serve as a security guide covering the IoT deployment segments. It is supposed to change as far as necessary in order to respond to the constant evolution in this domain.

Based on the analysis of the proposed security experiments, ARMOUR defines four IoT segments of an IoT deployment:

• Devices and data • (Wireless) connectivity • Platforms • Applications and Services

We propose to map OWASP IoT, oneM2M and GSMA to the ARMOUR Security Framework as depicted in the figure below. The ARMOUR security framework defines the security in terms of availability, integrity and confidentiality/privacy. It defines guidelines for each of the four segments described above and identifies elements to be secured.

Figure 10 ARMOUR Security Framework

In addition, it is highlighted that the oneM2M risk assessment methodology is extremely suitable for all IoT segments’ deployments thus vulnerabilities for each case study will be assessed through this security framework.

The ARMOUR security framework takes as entry the oneM2M vulnerabilities, threats and risk assessment methodology, and identifies eventually missing vulnerabilities and threats based on the seven experiments. The list of retained ARMOUR vulnerability patterns is provided in section 8.2.

22

4 Experiments description and requirements

4.1 Introduction

A total of seven experiments are planned to be conducted in the context of ARMOUR. These experiments have been selected to cover the main elements of IoT value chain being devices and data; connectivity; applications, services and platforms, as shown in Figure 11.

Figure 11: positioning of ARMOUR experiments over IoT value chain

This section provides a description of the experiments, identifies the requirements related to the experiments, highlights the targeted vulnerability patterns and the corresponding proposed solutions to be validated.

4.2 Experiments description

4.2.1 EXP1: Bootstrapping and group sharing procedures In this section, different aspects related to the execution of the experiments performed for the bootstrapping and group sharing stages are presented. On the one hand, the first type of experiment is focused on providing a mechanism that allows devices to authenticate and to request authorization to publish information in an IoT platform. On the other hand, the second type is intended to define a mechanism for secure information exchange between groups of devices through the platform.

Based on the above, the different threats that may arise in these two types of experiments, as well as the various countermeasures proposed to address them or palliate them are specified. Then, the scenarios and aspects associated with the execution of the experiments are described, besides showing the expected results of such execution. Finally, a set of specific requirements to consider during the performance of these experiments is defined.

23

4.2.1.1 Vulnerability patterns being addressed by the experiments (risk analysis) Before defining the scenarios that will be the basis for the experiments, it is necessary to perform an analysis of the risks to consider during the bootstrapping and group sharing stages. For that, we have based our analysis on the document TR-0008 of oneM2M [23] in which the main security problems in M2M systems are analysed. In such document, the most significant threats for the security in these types of systems are described, including an explanation of the issue caused by the threat, a description of the threat itself and a list of affected stakeholders, among other information. Besides, a set of countermeasures with the purpose of solving or, at least, palliating these threats is described.

Thus, the following table has been developed, detailing those vulnerabilities that may appear on the bootstrapping and group sharing stages.

Moreover, the Top 10 IoT Vulnerabilities Project of OWASP [24] have also been taken into account in order to organize and group the different threats defined above. Because of this, the following table shows such grouping, indicating for each vulnerability its OWASP rank. This exercise highlighted the lack of specificities of the OWASP ranking as a vulnerability can appear in several ranks.

OWASP rank Vulnerabilities

Insecure Web Interface (I1) Alteration of messaging between devices (V8)

Replay of messaging between devices (V9)

Unauthorized or corrupted applications or software in sensors or gateways (V10)

Session management and broken authentication (V17)

Security misconfiguration (V18)

Insufficient Authentication and Authorization (I2)

Discovery, deletion or replacement of keys stored in sensors, gateways or M2M infrastructure (V1, V2, V3, V4, V5)

Unauthorized or corrupted applications or software in sensors or gateways (V10)

Lack of Transport Encryption/Integrity Verification (I4)

Alteration of messaging between devices (V8)

Replay of messaging between devices (V9)

Eaves dropping and man in the middle attack (V13)

Privacy Concerns (I5) Insecure Cryptographic Storage (V19)

Insufficient Security Configurability (I8) Unauthorized or corrupted applications or software in sensors or gateways (V10)

Security misconfiguration (V18)

Insecure Software or Firmware (I9) Unauthorized or corrupted applications or software in sensors or gateways (V10)

Poor Physical Security (I10) Discovery, deletion or replacement of keys stored in sensors, gateways or M2M infrastructure (V1, V2, V3, V4, V5)

24

Once threats have been detected and have been grouped, in the next subsection several countermeasures to deal with them are provided.

4.2.1.2 Proposed solution to solve the vulnerability issue Previously, the vulnerabilities that may arise during the bootstrapping and group sharing stages have been described. So, in this subsection a set of countermeasures in order to solve them or palliate them is proposed. Such countermeasures, extracted from the document TR-0008 of oneM2M [23], are shown in the following table.

Countermeasure Description Related threats

Tamper resistant secure storage of keys within of sensors, gateways and M2M infrastructure equipment

Keys are securely stored in a HSM (whose tamper-resistance may be certified) residing within of sensors, gateways or M2M infrastructure equipment, which renders it infeasible for the attacker to discover the value of keys by logical or physical means

V1, V2, V3, V4, V5

Strong authentication to access to keys

Access to and/or modification of stored sensitive data and, in particular of the keys, requires strong (i.e. cryptographic) authentication of the accessing/modifying device, followed by authorization

V1, V2, V3, V4, V5

Use of security associations, mutual authentication and confidentiality

A security association is established between the communicating devices, which provides mutual authentication, integrity and confidentiality

V8

Proven resistance to man in the middle attacks

The security association between communicating entities uses protocols which are proven to resist man-in-the-middle attacks

V8

Limited life session keys Communications whose security is anchored in keys use session keys, i.e. keys with a limited lifetime, which can be set by security policy. Session keys can be derived from M2M keys

V8

Replay protection The protocol includes functionality to detect if all or part of a message is an unauthorised repeat of an earlier message or part of a message

V9

Keys can be derived from M2M keys

Communications whose security is anchored in keys use session keys, i.e. keys with a limited lifetime, which can be set by security policy. Session keys can be derived from M2M keys

V1, V2, V3, V4, V5, V9

Integrity verification The integrity of executable functions and files in sensors and gateways can be verified

V10

Policy-based actions Policy-based action can be taken to prevent the use of functions or of devices which fail the integrity verification test

V10

Secure communication link Establish secure communications link/ security association between relevant devices using modern cryptographic algorithms

V9 and V13

25

Security Controls Put in place encryption and/or strong session management security controls. Besides, implementing secure coding practices that enforce rigorous input data validation in system and services, database applications, and web services.

V17

Clean application architecture Implement a strong application architecture that provides good separation and security between components

V18

Standard algorithms Ensure appropriate strong standard algorithms and strong keys are used, and key management is in place.

V19

From the risk analysis exposed above and the countermeasures taken to address the different threats, then two scenarios for our experiments of the bootstrapping and group sharing stages will be defined.

4.2.1.3 Testing conditions and scenarios From the description previously exposed, in this subsection the two scenarios on which the experiments are based on for the bootstrapping and group sharing stages are described. Different entities that model the devices that will form part of these experiments appear in both scenarios. The description of such devices is shown below:

• Device. Sensor, or generally known as smart objects or nodes (which include sensors, actuators, etc.), are usually devices of constrained capabilities in terms of processing power, memory and communication bandwidth. Such devices are susceptible to provide resources or services to be accessed by users that could be devices acting on behalf of a human (H2M communication), or directly between devices (M2M communication).

• Gateway. To accomplish the communication with the Internet, a Gateway, or Border Router in 6LowPAN terminology is used. These devices can be also constrained, but when non-heavily constrained devices are used in this case, management of the LowPAN at a higher level can be accomplished in terms of authentication and authorization of the devices.

• AAA server. AAA server is an instantiation of the AAA framework that allow the management of a very large number of users in terms of authentication and authorization. AAA infrastructures can also be used for managing IoT networks with high number of devices that need to be authenticated and authorized before entering a domain or network.

• Capability Manager. Server that interacts with the Policy Decision Point (PDP) to get authorization decisions generating capability tokens accordingly.

• Attribute Authority. This entity interacts with gateways to issue and manage the private keys associated to them.

• Policy Decision Point (PDP). This entity is a component of a policy-based access control system that takes the determination of whether or not to authorize a device to perform an action over a resource, evaluating its access control policies.

26

• Pub/Sub server. Server that allows carrying out the registration, update and query of data, as well as sending notifications when changes on the registered information take place.

Thus, Figure 12 shows the first scenario, which is the basis of the experiment for bootstrapping stage.

Figure 12: Experiment scenario for bootstrapping stage

This scenario begins with the network access phase. For that purpose, an AAA infrastructure, based on RADIUS, is used, with a pass-through configuration. Thus, the sensor, acting as EAP peer, and AAA server exchange EAP messages in order to verify the identity of the first. Note that the number of EAP messages exchanged between these two devices depends on the authentication method used (EAP-TLS, EAP-MD5, EAP-AKA, etc.). From the result of authentication (Accept / Reject), the gateway, acting as EAP authenticator, will deny or allow network access to that sensor.

Once the network access phase has been successfully completed, the phase for obtaining the capability token starts. In this way, the sensor initiates the communication with the capability manager to request the token. The latter, before generate it, need to know if the sensor (subject) is able to publish (action) on the platform (resource). Thus, the capability manager sends to the PDP a XACML request and then, it evaluates its access control policies and takes an authorization decision. In the event that the decision is PERMIT, the capability manager generates and sends the capability token to the sensor, which allows publishing data on the IoT platform by the latter.

When the sensor is in possession of the capability token, the data publication phase begins. In this phase, the sensor communicates with the Pub/Sub server in order to publish information on the IoT platform, attached the token obtained in the previous phase. When receiving the request, the Pub/Sub server verifies the capability token and, if such verification is successful, the information is published.

27

The scenario described above shows a high level view of the bootstrapping stage using Extensible Authentication Protocol (EAP) and AAA protocols. Thus, there are two proposals that provide specific solutions considering EAP and AAA protocols that we will use in our experiments: PANATIKI and CoAP-EAP. On the one hand, PANATIKI is a lightweight version of a PANA client (PaC) for Contiki OS (PANATIKI) by adapting PANA for constrained devices. It implies removing part of the PaC state machine to make it suitable for constrained devices. Although PANATIKI does not make any modification to the standard, it does not implement some parts of the standard PaC state machine. In other words, it represents a reduced version of the standard, and a best case for PANA-based solutions. On the other hand, CoAP-EAP introduces an improvement to the EAP lower-layer focused on the use of protocols designed specifically for IoT. CoAP is the chosen protocol since it is one of the most proposed in several IoT stacks and it is also selected by several alliances involved in the development of IoT. They propose a bootstrapping service in CoAP that leverages the use of this protocol in the majority of smart objects. This way, the use of CoAP provides the re-use of expected code (CoAP) and a reduction in the message size, which translates in a better performance in low-power lossy networks over alternatives such as PANATIKI.

Moreover, the scenario in which the experiment for the group sharing stage is based, is shown in Figure 13.

Figure 13: Experiment scenario for group sharing stage

As observed, the scenario begins with the phase in which gateways obtain their private keys. In this phase, different gateways that will act as data consumers request to Attribute Authority the corresponding CP-ABE key. Note that, in that request, gateways include their certificate (X.509 or attributes certificate) so that the Attribute Authority can extract from it the set of attributes of such gateways and generate the corresponding CP-ABE keys for them.

28

Once the keys have been received by the gateways, the subscription phase starts. In this phase, the gateways that act as data consumers send subscription requests to the IoT platform for a given topic, such as humidity or temperature. Thus, when a device changes the topic value, the subscribed gateways will receive a notification with the updated information.

Next, the gateway that acts as a data producer initiates the publication and notification phase. Such gateway, before to publish the information on the platform, uses the CP-ABE cryptographic scheme to encrypt data under a policy of identity attributes (e.g. atr1 || (atr2 && atr3)). Once encrypted information, the gateway sends it to the Pub/Sub server to publish it over a given topic. When the Pub/Sub server receives the message, it checks if it has subscriptions registered of gateways consumers for that topic. Then, for each of the subscribed gateways, the Pub/Sub server sends them a notification with the new encrypted information associated with that topic. Finally, when a gateway consumer receives the data, it tries to decrypt them using its CP-ABE private key, which is associated with the set of attributes of such gateway. So, if its set of attributes satisfies the policy used in the encryption process, the information will be revealed. Note that all gateways consumers able to decrypt the data form a group with dynamic and ephemeral trust relationships between such devices.

As detailed in the beginning of this section, the experiments are based on the types of scenarios described above. In addition, these experiments will be carried out on the EPICURE platform, using its booking portal and its testbed planner, its OMF resources controller and its OMF experiments controller. Thus, in the following subsection the expected results of the experiments execution are shown.

4.2.1.4 Expected result, Data to be collected Once the scenarios for the bootstrapping and group sharing stages have been described, in this subsection is provided a list of aspects that are expected to demonstrate through the execution of the experiments described above. Such aspects are:

• An attacker cannot discover, delete or replace keys stored in entities (sensor, gateway o any component of the infrastructure) of the scenario.

• An attacker cannot alter or repeat messages between other entities without the knowledge of these.

• An attacker cannot install software in other entity if such software does not satisfy an integrity verification test.

• The data exchanged between two entities cannot be discovered by a third party. • Encrypted data can only be retrieved by the group of authorized entities.

Finally, in the next subsection several requirements to be considered to carry out the execution of the experiments are specified.

4.2.1.5 Specific Requirements In this subsection, the set of specific requirements to consider during the execution of the bootstrapping and group sharing experiments is defined. Such requirements are shown in the table below.

29

Table 5: Specific requirements for Bootstrapping and group sharing procedures experiment

Req. N° Requirement Type Priority Comment GEN1-1 CoAP Set-up MUST Bootstrapping experiment. It is used to

establish a secure bootstrapping. Besides, this protocol is used to exchange information between gateways and the Capability Manager

GEN1-2 DTLS Set-up MUST Bootstrapping experiment. Protocol to securely exchange information between gateways and Capability Manager

GEN1-3 HTTP Set-up MAY Bootstrapping and group sharing experiments. Protocol used to exchange information between Capability Manager and PDP and between gateway and Pub/Sub Server

GEN1-4 TLS Set-up MAY Bootstrapping and group sharing experiments. Protocol to securely exchange information between Capability Manager and PDP and between gateway and Pub/Sub Server

GEN1-5 Sensor Infrastructure MUST Bootstrapping experiment. It is the data source

GEN1-6 Gateway Infrastructure MUST Bootstrapping and group sharing experiments. Proxy to forward requests from the sensor to other components of the infrastructure, like AAA server, Capability Manager, PDP or Pub/Sub server

GEN1-7 XACML Infrastructure MUST Bootstrapping experiment. Framework used for policies representation

4.2.2 EXP2: Sensor node code hashing Sensor nodes are typically small resource-constrained devices with limited CPU, memory, and power resources [1]. In UNPARALLEL’s product prototypes, devices typically use a 16 Bits CPU working at 2 MHz, have about 8KB of SRAM and up to 128KB of flash memory. These prototypes are designed to have an energy footprint as small as possible, using as fewer resources as possible. These constraints result in the development of hardware specific applications without the usage of any operating system.

Sensor nodes are usually programmed using generally low-level programming languages, typically based on the one of the most widely used programming languages of all time: the C programming language (e.g. standard C, NesC, protothread-based C, etc.). There are many experienced programmers in C and on its compilers and libraries and even C hacking is one of the top hacking activities worldwide. This fact makes sensor nodes especially vulnerable to attacks and hacking in order to tamper code or even install new code that could provide erroneous data or even sniff the nearby network for data. The protection of the software installed and protection against illegitimate software installation are a major concern for UNPARALLEL, as deployed IoT solutions should be protected to ensure that no malicious behaviour will be executed by legitimate devices. This task

[1] Terminology for Constrained-Node Networks. IETF RFC 7228, May 2014. https://tools.ietf.org/html/rfc7228

https://tools.ietf.org/html/rfc7228

30

assumes a more complex dimension when dealing with large-scale Internet-of-Things environments.

Therefore, this experiment focuses on the identification of security mechanisms to ensure that both the device programed and programming entity (software providing servers, USB programmers, etc.) are legitimate. Such security mechanisms should provide authentication functionalities that allow devices and programmers to prove their identities. While the authentication of the devices allows to ensure that devices receive the software image that corresponds to their hardware and functional role, and tries to ensure that software images will not be delivered 3rd party entities. Hence, the device must not only prove its identity, but must also be able to authenticate and identify the software image installed. On the other hand, the authentication of the programing entity allows devices to trust (or not) on the software images received, being critical to determine if the code should be executed.

However, the addition of security mechanisms typically introduces a processing overhead when sending and receiving communication messages. This overhead increases the energy consumption of the devices and may compromise the maximum data rate in the network. Moreover, some security mechanisms require the exchange of control messages and may introduce redundant bytes on the communication messages, which will increase the time needed to transmit each message, and therefore increase the power consumption of the device. This experiment will study security mechanism that will address vulnerabilities associated with the distribution of code in a large-scale network, while having a special consideration for energy consumption constraints.

4.2.2.1 Vulnerability patterns being addressed by the experiment (risk analysis) A detailed analysis of the vulnerabilities explored in this experiment is required before the identification of proposed approaches and solutions to be addressed in this experiment. This experiment mainly focuses on security mechanisms to prevent malicious code to be disseminated on the network and executed on devices. Some of those security vulnerabilities are unavoidable if an authentication system is not implemented, therefore the existence of a device authentication system is an essential assumption that must be made. Starting from this assumption, two main types of attack were identified:

• Attacker device successfully authenticates into the system, and with rights to distribute executable software artefacts;

• Attacker device intercepts an executable software artefact and is able to inject malicious code in it.

Based on the analysis of those attack the following vulnerabilities were identified:

• Access to the hardware specific keys that are used to authenticate the device on the network: devices may use unique hardware identifiers for device authentication, which may be used by malicious applications/devices to successfully authenticate on the network.

o V1 - Discovery of Long-Term Service-Layer Keys Stored in M2M Devices or M2M Gateways

o V10 - Unauthorized or corrupted Applications or Software in M2M Devices/Gateways

o V14 - Transfer of keys via independent security element

31

• The messaging protocol for device authentication can also be exploited in order to discover authentication credentials and then perform illegitimate authentications on the network.

o V13 - Eaves Dropping/Man in the Middle Attack o V8 - Alteration of M2M Service-Layer Messaging between Entities o V9 - Replay of M2M Service-Layer Messaging between Entities

• Software images sent in software distribution images are susceptible to be intercepted and corrupted by attacking entities in attempts to make legitimate devices run malicious software

o V8 - Alteration of M2M Service-Layer Messaging between Entities o V7 – General Eaves Dropping/Man in the Middle Attack o V19 - Insecure Cryptographic Storage

The identified vulnerability patterns can be grouped according to some of the top ten security vulnerabilities identified by the OWASP IoT project. This grouping is identified in the table below where each vulnerability pattern can be associated with different OWASP IoT security vulnerabilities.

OWASP rank Vulnerabilities Description

I2 - Insufficient Authentication and Authorization (I2)

Replay of Authentication Messaging between Entities (V9)

Attacking devices use authentication messages sent by others devices to authenticate

I4 - Lack of Transport Encryption/Integrity Verification (I4)

Discovery of Long-Term Service-Layer Keys Stored in Devices or Gateways (V1)

Discover of hardware specific keys in communication messages

Authentication Message Eaves Dropping/Man in the Middle Attack (V13)

Authentication information can be extracted from messages

Alteration of Authentication Messaging between Entities (V8)

Authentication messages are altered to authenticate attacking devices

Software distribution Message Eaves Dropping/Man in the Middle Attack (V7)

Attacker can extract software images from software distribution messages

Alteration of Software Distribution Messaging between Entities (V8)

Attacker changes the software images in software distribution messages

Insecure Cryptographic Storage (V19)

Information that should be protected lacks proper encryption

I9 - Insecure Software or Firmware

Unauthorized or corrupted Applications or Software in Devices (V10)

Malicious software can be installed on devices by physical access (lack of firmware protection)

I10 - Poor Physical Security

Discovery of Long-Term Service-Layer Keys Stored in Devices or Gateways (V1)

Discover of hardware specific keys by inspection of hardware

32

Unauthorized or corrupted Applications or Software in Devices (V10)

Attacker as physical access to legitimate devices and its physical programming interfaces

Transfer of keys via independent security element (V14)

Hardware modules with keys may be removed from legitimate device and deployed on an attacking device

Insecure Cryptographic Storage (V19)

Attacker as access to information that should be protected

4.2.2.2 Proposed solution to solve the vulnerability issue Previously, the vulnerabilities that may arise during the authentication and software distribution stages have been described. So, in this subsection a set of countermeasures in order to solve them or palliate them is proposed. Such countermeasures, extracted from the report TR-0008 of oneM2M, are shown in the following table.


Tamper resistant storage of keys within sensors and gateways

Keys are stored inside devices using mechanisms or resources (e.g. Hardware Security Module) that make difficult for the attacker to discover the value of keys by logical or physical means

V1

Integrity verification The integrity of software images received must be verified by devices

V10

Policy-based actions Policy-based action can be taken to prevent the execution of malicious software which failed the integrity verification test

V10

Physical and logical binding of HSM to sensors or gateway

Resources storage containing the keys is bound to devices and servers using physical and/or logical means

V14


A security association is established between the devices and software provisioning servers, which provides mutual authentication, integrity and confidentiality

V8



V8

Limited life session keys Communications whose security is anchored in keys use session keys, i.e. keys with a limited lifetime, which can be set by security policy. Session keys can be derived from master/hardware

V8

33

keys


V19

Session keys can be derived from master/hardware keys

Communications whose security is anchored in keys use session keys, i.e. keys with a limited lifetime, which can be set by security policy. Session keys can be derived from M2M keys

V1 and V9

Secure communication link Establish secure communications link/ security association between relevant devices and software provisioning server using modern cryptographic algorithms

V13, V9 and V7

Standard algorithms Ensure appropriate strong standard algorithms and strong keys are used, and key management is in place.

V19

4.2.2.3 Testing conditions and scenarios In this section are described the scenarios for testing the security mechanisms associated with the software distribution process and their specific conditions. These testing scenarios are used to identify the main communication messages related with the entities authentication and software distribution stages, as well as to define a scenario where scalability can be tested and analysed to identify its impact on the overall security aspects.

Since energy consumption is an important aspect for UNPARALLEL, energy consumption of devices should be constantly measured in order to assess the impact of each security mechanism on the power consumption, which will be an important aspect in the identification of the encryption algorithms that should be used.

There are three entities that assume special relevance in the testing scenarios:

• Provisioning Server: Repository that stores the software images meant to be installed on devices. This server is also responsible for the validation of the identity of devices that request software updates.

• Device: Node located the edge of the network with sensing or actuation capabilities. Devices have constrained resources either at the level of computation power and data storage, as well as at the level of power supply. Given the scarcity of resources, no generic operating system is used, being developed hardware specific applications to achieve greater efficiency.

• Device Group: Group of devices with the same role. Different roles imply different functional behaviour, and therefore, the execution of different software. Devices

34

belonging to a Device Group only have permissions to run software images associated with that group.

Several other network elements (such as gateways) may exist between devices and provisioning servers. Despite the fact that these network elements may be used to exploit some security vulnerabilities, they don’t have an active role on the software distribution management.

The first testing scenario is shown in Figure 14, where a Provisioning Server receives a new software image do be executed by devices. The possible security issues related with this step are out of the scope of this testing. After receiving a new software image, the provisioning server announces it to all devices in the network by the means of broadcast/multicast messages. When a device receives the announcement, it may decide to request a software update and sends a Software Access Request (step 3), starting the authentication process. This authentication protocol is strongly inspired on the Extensible Authentication Protocol (EAP), where adaptations may be made to improve the efficiency based on the conditions of the testing scenario.

In the Software Access Request message, the device sends its identification information which allow to identify its hardware and the current version of the software that is running at the device. When the Provisioning Server receives this message, it tries to validate the Device ID by, for instance, consulting registry tables or running validation algorithms over the ID. If the Device ID is considered valid, then the Provisioning Server will send a challenge to the device. An exchange of challenges will occur to allow the Provisioning server to prove its identity to the device and the latter to prove that the software that it is running is legitimate.

To achieve this purpose, a Keyed-Hashing for Message Authentication (HMAC) mechanism will be used where expressions and software fingerprint information will be combined using a Hashing algorithm. Software fingerprints can be obtained from the execution of specific functions that collect and process metrics from the software, or can consist in a message/code embedded within the software that can be obtained using specific methods. Software fingerprints are meant to be used to verify the authenticity of the software because fingerprints are supposed to change whenever the software is changed. Therefore, only the entities that know the fingerprint information of the software version being used will be able to produce the hash code. When the device informs the provisioning server which software version it is running, the provisioning server can search in its database which fingerprint should be used in the challenge process.

35

Figure 14: Single device software update stage

If the challenge process was successful, then a secure connection can be established and the software image is transferred from the Provisioning Server to the device through an encrypted channel. In the whole process neither the software nor the fingerprints should be exchanged using unprotected communication channels.

In Figure 15 is presented the second testing scenario where the concept of roles is introduced. There can be devices in the system with different roles, whose hardware and/or software may differ in order to allow devices to have a different behaviour (e.g. sense different physical phenomena, execute actuation actions, etc.). Therefore, devices with different roles will probably receive different software updates. This need requires a mechanism to identify which group can have access to which software updates, supporting the existence of a large number of different groups, typical in large-scale systems.

In this scenario, software images must be associated with one or more role groups. When the Provisioning server announces that a new software is available, it also identifies which role groups are able to receive the software update. In Figure 15, the announcement of a new software available is propagated for all groups but only the group with permission to install it (Device Group 1) starts the authentication process.

36

Figure 15: Software update with support to role groups

Different encryption algorithms, hashing functions, and software fingerprinting methods will be tested on both testing scenarios in order to identify the one that provide best security and energy performances.

4.2.2.4 Expected result, Data to be collected The execution of the testing scenarios previously described is expected to provide the following results:

• Only legitimate devices, running legitimate software receive new software images;

• Devices only run software distributed by legitimate software providing servers;

• Legitimate devices only have access to software corresponding to their role; • Software images are always transferred on encrypted channels and can only

be decrypted by legitimate entities. In addition to security related data, it is also expected that data related to the power consumption of devices will be collected during the execution of the different security processes, such as different encryption algorithms or different message-digest algorithms.

37

4.2.2.5 Specific Requirements Table 6: specific requirements Sensor node code hashing experiment

Req. N° Requirement Type Priority Comment GEN2-1 Platform must allow over the air

programming of the nodes Set-up MUST Devices

should be able to update software over the network

GEN2-2 It SHOULD be possible to track the devices which were used for routing of the programming code

Analysis SHOULD

GEN2-3 It MUST be possible to verify that the code stored on the device was not improperly modified during the tests

Analysis MUST

GEN2-4 It must be possible for the programmer to be able to monitor the tests

Analysis MUST

GEN2-5 It must be possible to side-load code into the device, to simulate improper code changes

Control MUST

GEN2-6 Nodes must have a trackable unique-id

Infrastructure MUST

GEN2-7 It must be possible to monitor the power consumption of devices

Infrastructure/analysis MUST

GEN2-8 It must be possible to program the behaviour of devices without the use of an Operating Systems

Infrastructure/Set-up MUST Experimenter should be able to configure devices with specific applications, without being enforced the use of a operation system (RIOT, Contiki, TinyOS, etc.)

GEN2-9 It must be possible to reserve constrained device

Infrastructure MUST Testbed must have devices with constrained resources

GEN2-10 It must be possible to reserve server/gateway with storage

Infrastructure MUST Testbed must have devices that can play the role of provisioning server

GEN2-11 It should be possible to configure sniffers

Infrastructure SHOULD

4.2.3 EXP3: Secured bootstrapping/join for the IoT The main objective of the experiment is to test, prototype and provide secured communication during the join/bootstrap procedure. Within the IoT context, we also want to guarantee standards-based and highly reliable communication. This last point will be

38

achieved by using and operating IETF 6TiSCH protocol stack. 6TiSCH builds on the IEEE802.15.4 TSCH MAC. The Medium access Control (MAC) of IEEE802.15.4 has evolved with the IEEE802.15.4e Time slotted Channel Hopping (TSCH) mode to provide deterministic properties on wireless networks. In order to enable the convergence of IT and OT in LLN environments, 6TiSCH ports the IETF suite of protocols that are defined for such environments over the TSCH MAC. 6TiSCH also provides large scaling capabilities, which, in a number of scenarios, require the addition of a high-speed and reliable backbone and the use of IP version 6 (IPv6). The main goal of using 6TiSCH is to target and reach 99,99% packet delivery between IoT nodes and the infrastructure. The use of such protocol stack appears to be a must be and mandatory. We also emphasis on the use of IETF protocol stack to guarantee fully standard communication protocol stacks.

6TiSCH operates on IEEE802.15.4 and expects link-layer security to be enabled at all times between connected devices. A set of two keys (K1 and K2) are used to authenticate and or encrypt link layer frames. A security design team has been created in the IETF 6TiSCH working group, and is actively working on defining a security architecture. The ARMOUR plays a key role as it allows that design team to assess the “secure” nature of the architecture during the standardization phase. This close collaboration between ARMOUR and the IETF 6TiSCH security design team is a unique opportunity, and contributes to the impact of the ARMOUR project.

The main goal of this experiment is to implement and test the Join Process being defined by IETF 6TiSCH.

4.2.3.1 Vulnerability patterns being addressed by the experiment (risk analysis) The main vulnerability is that an attacker device succeeds to authenticate into the system during the first step of the device join process. If an external device succeeds, it can send wrong values, do denial of attack with the deterministic 6TiSCH architecture and thus damage the global schedule and the target reliability. The main vulnerabilities are:

• Access to specific keys used to authenticate the device on the network:

o V1 - Discovery of Long-Term Service-Layer Keys Stored in M2M Devices or M2M Gateways

o V14 - Transfer of keys via independent security element

• Discover authentication credentials and perform illegitimate authentications on the network.

o V13 - Eaves Dropping/Man in the Middle Attack

o V8 - Alteration of M2M Service-Layer Messaging between Entities

o V9 - Replay of M2M Service-Layer Messaging between Entities

4.2.3.2 Proposed solution to solve the vulnerability issue

39


Keys stored using tamper-resistant techniques

The keys which are stored in the deviced are protected by a tamper-resistant mechanism, which might involve hardware or software. This makes it harder for an attacker to retrieve keying material.

V1

Use of COSE security mechanisms to protect transfer of sensitive elements

The IETF COSE working group is defining security mechanisms, called “Object Security” to protect the communication between different elements in the network.

V14

Secured application-level communication

Eavesdropping is always possible, and trivial to do in a wireless environment. For this reason the solution tested in this experiment uses IETF COSE to protect the application-level payload.

V13

Use of authentication, authorization and integrity protection

The COSE security mechanisms includes integrity protection. Moreover, authentication and authorization are done by a “security handshake” at the beginning of the transaction

V8

Use of nonce for replay protection A nonce is use to protect against replay protection. The information being replayed will be discarded by the receiver and will have no effect.

V9

4.2.3.3 Testing conditions and scenarios The solution we propose is based on IETF 6TiSCH Join Process2. The architecture specifies three logical elements to describe the join process:

1. Joining Node (JN): Node that wishes to become part of the network; 2. Join Coordination Entity (JCE): A Join Coordination Entity (JCE) that arbitrates

network access and hands out network parameters (such as keying material); 3. Join Assistant (JA), a one-hop (radio) neighbour of the joining node that acts as

proxy network node and may provide connectivity with the JCE.

The join protocol consists of three major activities:

1. Device Authentication: The JN and the JA mutually authenticate each other and establish a shared key, so as to ensure on-going authenticated communications. This may involve a server as a third party.

2 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e draft-ietf-6tisch-architecture-05)

40

2. Authorization: The JA decides on whether/how to authorize a JN (if denied, this may result in loss of bandwidth). Conversely, the JN decides on whether/how to authorize the network (if denied it will not join the network). Authorization decisions may involve other nodes in the network.

3. Configuration/Parameterization: The JA distributes configuration information to the JN, such as scheduling information, IP address assignment information, and network policies. This may originate from other network devices, for which the JA may act as proxy. This step may also include distribution of information from the JN to the JA and other nodes in the network and, more generally, synchronization of information between these entities.

.

Figure 16: Network joining, with only authorization by third party

Note that this security solution uses CBOR-based object signing and encryption defined by the IETF COSE working group. Concise Binary Object Representation (CBOR) is a concise binary format for the serialization of data structured to an extended version of the JSON data model and the COSE working group seeks to create CBOR-based object signing and encryption formats.

The scenarios will be classic in term of testing. We’ll test 4 nodes. Three of them will support the stack 6TiSCH / COSE and one node will be malicious and will try to be the man in the middle or to join the network without any right. The first implementation will be done in the OpenWSN protocol stack. In a second step, we may port the 6TiSCH / COSE solution to RIOT.

4.2.3.4 Expected result, Data to be collected Non authorized node cannot join a secured network with “limited” power/computing resources (the malicious node is in the same order of secured IoT nodes in terms of memory, wireless capacity and computing resources).

4.2.3.5 Specific Requirements Table 7: specific requirements related to the Secured bootstrapping/join for the IoT experiment

Req. N° Requirement Type Priority GEN3-1 Configure sniffer Infrastructure SHOULD

GEN3-2 inject interference (e.g. JamLab) Control SHOULD

41

GEN3-3 inject malicious packets / replay / malicious nodes Control SHOULD GEN3-4 Node supporting OpenWSN / 6TiSCH / COSE Set-up MUST GEN3-5 Node supporting RIOT / OTA Set-up MUST GEN3-6 Node supporting RIOT / OTA / COSE Set-up MAY GEN3-7 Node supporting OpenWSN / 6TiSCH / COSE / OTA Set-up MAY

4.2.4 EXP4: Secured OS / Over the air updates The main objective of the experiment is to test, prototype and provide secured OTA (Over the air) updates for RIOT. Over-the-air programming (OTA) refers to various methods of distributing new software, configuration settings (e.g. credentials) to devices.

RIOT powers the Internet of Things like Linux powers the Internet. RIOT is a free, open source operating system. RIOT implements all relevant open standards supporting an Internet of Things that is connected, secure, durable, and privacy-friendly. Since consumers expect their devices to stay up to date with the latest features and performance improvements, Firmware OTA is now a standard required feature for connected devices.

There is a crucial need to get OTA functionalities into RIOT in order to sustain a high level of security:

• separate update code from main current code

• download binary with high level protocol over encrypted channel

• signed images

• roll-back mechanism if new image is not functional

The goal is to implement and test a secured OTA procedure in RIOT.

4.2.4.1 Vulnerability patterns being addressed by the experiment (risk analysis) The main vulnerability addressed is the fact that when an IoT software vulnerability is detected, the vulnerability stays until a patch is provided and the software updated on the IoT device. The mechanism enables vulnerabilities to be patched on the fly, by dynamically modifying the firmware at work on IoT devices. Only signed/authorized code is updated on the IoT devices.

The main vulnerability is:

• Access to specific keys used to authenticate the device on the network:

o V10 – Unauthorized, unsigned or corrupted Applications or Software is updated on a Iot Device.

42

4.2.4.2 Proposed solution to solve the vulnerability issue

Figure 17: Architecture proposal. Example of a double internal flash and relocation. The idea here is to relocate on-device to avoid having multiple images.

The goal is to implement this architecture within RIOT in a first step to provide RIOT/OTA functionalities. In a second step, optionally, we may conform to RIOT/OTA/COSE for bootstrap/join security.

4.2.4.3 Testing conditions and scenarios The following 3 scenarios will be on IoT-LAB, assuming the necessary encryption/signature keys are pre-shared.

Functional Firmware Scenario:

1. The tested node receives a new firmware via it’s radio interface, over UDP and high-level encrypted channel.

2. The node stores the new firmware and checks the signature of this firmware. 3. The signature checks right. 4. The node boots the new firmware and verifies its functionality. 5. The new firmware functionality is confirmed to be correct. 6. Expected result: the node has successfully updated its firmware

Corrupt Firmware Scenario:

1. The tested node receives a new firmware via it’s radio interface, over UDP and high-level encrypted channel.

2. The node stores the new firmware and checks the signature of this firmware. 3. The signature checks right. 4. The node boots the new firmware and verifies its functionality. 5. The new firmware’s functionality cannot be confirmed. 6. Expected result: the node rolls back to the old firmware.

Malicious Firmware Scenario

43

1. The tested node receives a malicious firmware via it’s radio interface, over UDP and high-level encrypted channel.

2. The node stores the firmware and checks the signature of this firmware. 3. The signature checks wrong. 4. Expected result: the node does not install the received firmware.

4.2.4.4 Expected result, Data to be collected Functional firmware, properly signed by authorized entity, is successfully received, verified, installed and booted on an IoT device in the IoT-LAB testbed running RIOT.

If the received firmware is either malicious, or non-functional, the IoT device continues to run the previous firmware.

4.2.4.5 Specific Requirements Table 8: Specific requirements related to the Secured OS / Over the air updates experiment

Req. N° Requirement Type Priority

GEN4-1 Configure sniffer Infrastructure SHOULD

GEN4-2 inject interference (e.g. JamLab) Control SHOULD GEN4-3 inject malicious packets / replay / evil nodes Control SHOULD GEN4-4 Node supporting OpenWSN / 6TiSCH / COSE Set-up MUST GEN4-5 Node supporting RIOT / OTA Set-up MUST GEN4-6 Node supporting RIOT / OTA / COSE Set-up MAY GEN4-7 Node supporting OpenWSN / 6TiSCH / COSE / OTA Set-up MAY

4.2.5 EXP5: Trust aware wireless sensors networks routing The main objective of the experiment is to evaluate the performance of distributed trust-aware WSN routing solutions in real large-scale deployments, under the presence of malicious nodes, lossy links or under adverse conditions. The trust solutions under test must, on one hand, be able to tolerate several types of attacks and, on the other hand, achieve optimal routing and application goals based on high-end theoretical frameworks. In more detail, the experiment will evaluate the performance of single or composite routing metrics, incorporating trust, energy and other criteria. Single metrics include Packet Forwarding Indicator (PFI), Expected Transmission (ETX), Hop Count (HC) and Remaining Energy (RE), while compositions of them with well-established metrics will be considered. Both lexicographic and additive metric composition approaches will be tested and compared against routing and application performance under (adverse/severe) testing conditions. Moreover, the experiment will explore different metric configurations, allowing for refining parameter configuration for diverse application domains (e.g. find the optimal weight combination for the additive composition).

4.2.5.1 Vulnerability patterns being addressed by the experiment (risk analysis) Before defining the scenarios that will form the basis for the experiments to be conducted, we herein present the vulnerabilities related to this set of experiments, taken from the ARMOUR selected vulnerabilities (see Section 8.2). In this respect, the threats and vulnerabilities affecting the security of our solution will be presented, including an explanation of the issue caused by the threat, a description of the threat itself and a list of affected stakeholders, among other information.

• V8 - Alteration of M2M Service-Layer Messaging between Entities

44

• V9 - Replay of M2M Service-Layer Messaging between Entities • V10 - Unauthorized or corrupted Applications or Software in M2M

Devices/Gateways • V12 - M2M Security Context Awareness • V13 - Eaves Dropping/Man in the Middle Attack

4.2.5.2 Proposed solution to solve the vulnerability issue Previously, the vulnerabilities that may arise for trust-aware routing experiments have been described. So, in this subsection a set of countermeasures in order to solve them or palliate them is proposed. Such countermeasures, extracted from the report TR-0008 of oneM2M [23], are shown in the following table.

Countermeasure Description Related vulnerabilities



V8


The security association between communicating entities uses protocols which are proven to resist man-in-the-middle attacks.

V8


V9

Context Inventory and Assessment on Sensitivity

The different operational contexts of the M2M Systems assets should be inventoried and assessed for sensitivity to confidentiality, integrity and availability requirements.

V12

Secure communication link

Establish secure communications link/ security association between relevant devices using modern cryptographic algorithms

V9, V13

Policy-based actions Policy-based action can be taken to prevent the use of functions or of devices which fail the integrity verification test

V10

From the risk analysis exposed above and the countermeasures taken to address the different threats, then the scenarios for our experiments will be defined in the next sections.

4.2.5.3 Testing conditions and scenarios This scenario focuses on the integration and demonstration of the trust-aware routing protocol in a security-related context. In particular, we consider a large-scale WSN deployment in the presence of malicious nodes. The routing metrics that are utilized by the routing protocol for establishing the routes to forward the data packets, will be shown to efficiently detect any malicious nodes (e.g. grey or black nodes that drop part of or all of their incoming traffic, replay attacker that re-send previous messages and integrity attacks

45

from nodes altering message data) and re-route the data traffic around them. Also, this scenario will demonstrate the effectiveness of excluding a node that does not support encryption capabilities and avoids replay and alteration attacks by overhearing the medium/channel. Thus, robustness and attack resistance of the routing protocol will be evaluated and demonstrated. As shown in Figure 18: Trust-aware routing scenario and demonstration., several attacks (in terms of type and number) will be applied to evaluate the reliability of the proposed routing protocol. Most importantly, the ability of the routing protocol to adapt to threats and attacks taking into consideration the use case context will be demonstrated. As a representative example, a node will be able to identify the presence of malicious nodes in the path towards the sink node and bypass them. Although this scenario is mostly based on the Packet Forwarding Indicator (PFI) metric, capturing the trustworthiness of neighbouring nodes, other routing metrics developed (and tested in the simulation platforms) can be combined with PFI metric to increase performance characteristics of the routing protocol, such as Remaining Energy (RE), Expected Transmissions (ETX), Hop-Count (HC), etc. In analogy, replay attacks and modification attacks can be identified, excluding malicious nodes from future routing decisions in a dynamic and customizable way.

In this scenario, a number of nodes will be programmed as misbehaving nodes that must be detected and by-passed from the trust-aware routing module by applying the countermeasures for each type of attack. In particular, four types of attackers are involved in this scenario: black hole attackers (representing nodes that drop all forwarding traffic), grey hole attackers (nodes that drop forwarding traffic in a random manner), replay attackers (re-sending previous messages), modification attackers (nodes that modify the message data to cause instabilities or security breaches in the WSN).

Figure 18: Trust-aware routing scenario and demonstration.

4.2.5.4 Expected result, Data to be collected The list of functionalities demonstrated in this scenario includes:

46

1. Support of reactive-based selection of forwarding nodes. This will prove the dynamicity of the enhanced RPL-based routing protocol in terms of mitigating several attacks and vulnerabilities, as described above.

2. Mitigate several attacks on networking and application layers, such as black-hole, grey-hole, replay, alteration attacks, etc.

3. Network immunity against routing attacks that disrupt network operation. Scenarios that include a large percentage of malicious nodes will be demonstrated to prove that the applied countermeasures properly address the vulnerabilities.

4. Dynamic policy-based actions. Applying dynamic policy-based actions on routing layer in order to discover and select alternative paths to the destination node.

5. Overhear network channels. This is a strong countermeasure against replay and alteration attacks performed in the network.

4.2.5.5 Specific Requirements Table 9: specific requirements for Trust aware wireless sensors networks routing experiment

Req. N° Requirement Type Priority Comment GEN5-1 Motes must support at least TinyOS and

ContikiOS protocol stack Set-up MUST TelosB, Zolertia

Z1 GEN5-2 Experiment should include mobile motes Infrastructure SHOULD TinyOS/ContikiOS

GEN5-3 Infrastructure must provide a Linux-based Wireshark implementation as a network-wide sniffer

Control MUST

GEN5-4 Infrastructure must provide a Linux-based Gateway supporting CoAP

Infrastructure MUST

GEN5-5 Remote access to motes for OTA (re)programming

Control MUST

GEN5-6 The programmer may require access to debugger

Analysis MAY

GEN5-7 Infrastructure must support e2e IPv6 connectivity during set-up

Set-up MUST

4.2.6 EXP6: Secure IoT Service Discovery This section deals with the execution of a set of experiments proving the robustness and efficiency of secure service discovery achieved by an innovative group-based solution combining DTLS over CoAP protocol.

To demonstrate such security characteristics, a number of threats will be described and countermeasures will be applied to mitigate the vulnerabilities in large-scale wireless sensor networks. Based on the above, the different threats that may arise in these experiments, as well as the various countermeasures proposed to address them or palliate them are specified in the next two subsections. Moreover, the scenarios and testing conditions associated with the execution of the experiments are described, and the expected results are explicitly mentioned. Finally, a set of specific requirements to consider during the performance of these experiments is defined.

4.2.6.1 Vulnerability patterns being addressed by the experiment (risk analysis) Before defining the scenarios that will be the basis for the experiments, it is necessary to perform an analysis of the risks to consider for experimenting and demonstrating the security capabilities achieved in this service discovery landscape. In the next table, we

47

describe the vulnerabilities, using the patterns listed in section 8.2, the affected systems and platforms as well as the impact on WSN operation with respect to security.

• V2 - Deletion of Long-Term Service-Layer Keys stored in M2M Devices or M2M Gateways

• V3 - Replacement of Long-Term Service-Layer Keys stored in M2M Devices or M2M Gateways

• V8 - Alteration of M2M Service-Layer Messaging between Entities • V9 - Replay of M2M Service-Layer Messaging between Entities • V10 - Unauthorized or corrupted Applications or Software in M2M

Devices/Gateways • V13 - Eaves Dropping/Man in the Middle Attack • V19 - Insecure Cryptographic Storage

4.2.6.2 Proposed solution to solve the vulnerability issue This subsection includes a set of countermeasures in order to solve the aforementioned threats/vulnerabilities. Such countermeasures, extracted from the report TR-0008 of oneM2M [23], are shown in the following table.


Strong authentication for access to keys

Access to and/or modification of stored sensitive data and, in particular of the keys, requires strong (i.e. cryptographic) authentication of the accessing/modifying device, followed by authorisation

V2, V3



V8



V8

Secure communication link

Establish secure communications link/ security association between relevant devices using modern cryptographic algorithms

V9, V13

Integrity verification

The integrity of executable functions and files in sensors and gateways can be verified

V10

Standard algorithms

Ensure appropriate strong standard algorithms and strong keys are used, and key management is in place.

V19

4.2.6.3 Testing conditions and scenarios The scenario will include the registration, key exchange over secure channel and attempts to break security measures on an implemented lightweight software library that provides a

48

datagram server with DTLS support for use in constrained (Class 1 or 2) IoT devices, as depicted in Figure 19.

Figure 19: Secure Service Discovery scenario and demonstration.

The wireless sensor networks will consist of several nodes connected to IoT Gateway(s). In such an environment, we will demonstrate the performance and validate the efficiency of security solutions imposed by the ARMOUR framework by different encryption and integrity methods and libraries installed to motes and gateways under the concept of group keying. Thus, the scenario will validate service and resource discovery based on CoAP server enhanced with DTLS protocol. Moreover, the utilization of encryption protocols will be included as a metric in the trust-aware routing scenario, integrating both experiments and as a consequence, addressing more vulnerabilities.

4.2.6.4 Expected result, Data to be collected The major outcome of this scenario is to evaluate and demonstrate in large-scale experiments the performance related to the encryption algorithms and the DTLS handshake procedure in constrained environments, mitigating the following attacks/vulnerabilities:

• An attacker cannot delete or replace keys stored in entities (either sensor or gateway) of the scenario.

• An attacker cannot perform attacks related to alteration and/or replay of messages exchanged between entities within the wireless sensor network.

• An attacker installing malicious/corrupted software in entities will be identified by proper mechanisms in place (e.g. integrity verification test, overhearing channel).

• Encrypted data can only be retrieved by the group of authorized entities.

49

4.2.6.5 Specific Requirements Table 10: specific requirements related to the Secure IoT Service Discovery experiment.

Req. N° Requirement Type Priority Comment GEN6-1 Motes must support at least TinyOS and ContikiOS

protocol stack Set-up MUST TelosB,

Zolertia Z1 GEN6-2 Infrastructure must provide a Linux-based Wireshark

implementation as a network-wide sniffer Control MUST

GEN6-3 Infrastructure must provide a Linux-based Gateway supporting CoAP

Infrastructure MUST

GEN6-4 Gateway must also support TLS/DTLS Set-up MUST GEN6-5 Remote access to motes for OTA (re)programming Control MUST GEN6-6 The programmer may require access to debugger Analysis MAY GEN6-7 Infrastructure must support e2e IPv6 connectivity

during set-up Set-up MUST

GEN6-8 Gateway should support IPv6-IPv4 translation Control SHOULD GEN6-9 The infrastructure must support PSK, HMAC-

SHA256, AES-128, etc. Set-up MUST

4.2.7 EXP 7: Secure IoT platforms

4.2.7.1 Vulnerability patterns being addressed by the experiment (risk analysis) This experiment has a different positioning from the other experiments: rather than intending to propose solutions to solve the vulnerability issues, the experiment aims at evaluating through actual testing, the extent to which the vulnerabilities exist or not within the tested system. The experiment will focus on two IoT platforms attracting major interest in Europe and worldwide:

• FIWARE: an ecosystem providing APIs and open-source implementation for lightweight and simple means to gather, publish, query and subscribe context-based, real-time information. This independent community includes 60 cities in the OASC [25] alliance who adopt FIWARE NGSI API.

• oneM2M established to develop a single horizontal platform for the exchange and sharing of M2M/IoT data among all applications. oneM2M is creating a distributed software layer which provides a framework for interworking with different technologies [26].

As a global standardisation initiative, oneM2M conducted a more comprehensive analysis of security risks (see section 3.1.2) and is thus used as a starting point to identify platform level vulnerability patterns.

4.2.7.2 Proposed solution to evaluate the vulnerability level This experiment intends to provide vulnerability-based security testing of the above mentioned platforms with an initial focus on oneM2M. All vulnerabilities identified within section 8.2 are thus of potential interest. However, some of them being already covered by the other experiments, it has been decided to start with the uncovered vulnerability patterns, thus to provide a full coverage of the vulnerabilities. Moreover, some of the vulnerabilities such as V1 to V5, considering the use of encryption keys is related to the different use case scenarios involving different entities from the IoT segments. An end-to-end testing approach involving all entities and capturing the business process could be necessary. Thus, the goal would be to expand the security testing in EXP 7 as the project

50

progresses and with respect to the other experiment’s needs. Nevertheless, the primarily focus of EXP7 will be on:

• V6 - Discovery of sensitive Data in M2M Devices or M2M Gateways • V8 - Alteration of M2M Service-Layer Messaging between Entities • V9 - Replay of M2M Service-Layer Messaging between Entities • V16 – Injection • V17 - Session Management and Broken Authentication • V18 - Security Misconfiguration • V20 - Invalid Input Data

A strong relation is built with the oneM2M standardisation Alliance and progresses made within ARMOUR will be contributed to the oneM2M Alliance to both security (SEC) and test (TST) working groups. To this aim, EGM is officially involved into the oneM2M standardisation Alliance.

4.2.7.3 Testing conditions and scenarios The experiment will build upon Model Based Testing (MBT) principles to run both compliance testing and exploratory testing.

From the ISTQB Syllabus [27]: Model-Based Testing (MBT) is an advanced test approach using models for testing. It extends and supports classic test design techniques such as equivalence partitioning, boundary value analysis, decision table testing, state transition testing, and use case testing. The basic idea is to improve the quality and efficiency of the test design and test implementation activities by:

• Designing a comprehensive MBT model, typically using tools, based on project test objectives.

• Providing an MBT model as a test design specification. This model includes a high degree of formal and detailed information that is sufficient to automatically generate the test cases directly from the MBT model.

MBT and its artefacts are closely integrated with the processes of the organization as well as with the methods, technical environments, tools, and any specific lifecycle processes.

Model-Based Testing is an approach based on creating test cases derived from a behaviour model, called the test model, of the system under test. This test model describes the expected behaviour of the test object. The tests cases are automatically generated from the test model thanks to a MBT tool able to read the model and automatically generate test cases which are optimised in term of number, requirements coverage, etc.

The test model is created and a tool that will create test cases can read this model. A standard approach uses an UML (Unified Modelling Language) model with constrains applied using OCL (Object Constraint Language) and can also improve the process of designing the model to read the test model and then generate test cases. UML Diagrams used for modeling are: Class Diagram, Sequence Diagram, States Charts Diagram. We have sometimes FSM (Finite States Machines) or EFSM (Extends Finite States Machines).

51

In our compliance testing context, the system under test (oneM2M platform) is considered as a black box and MBT is used to generate of executable test cases that include oracle information, such as the expected output values of the SUT, or some automated checks on the actual output values to see if they are correct [28].

In addition to compliance testing, exploratory testing has been proven to be very effective testing approach. Exploratory testing is creative and experience based approach in which test design, execution and learning are parallel activities, thus it gives rapid feed-back to the test expert.

Such techniques are extremely useful to exercise unexpected paths in the system and thus improve the IoT platform robustness. For this experiment we suggest to apply automatic exploratory (on-line) approach based on MBT models that will create additional test cases to exercise the platform behaviour. We select compliance scenarios, which will be used as basis for the automated exploratory testing. For this purpose, we will extend SMA MbeeTle tool for exploratory testing. MbeeTle will use the same models as for compliance testing and during ARMOUR its strategies might need extension in order to produce effective and efficient test cases.

4.2.7.4 Expected result, Data to be collected Experiments will take as input the platform specifications as expressed within the TS003 specification of oneM2M related to the targeted vulnerabilities. A first extraction of security requirements has been made from that document. They are listed in section 8.3. The analysis shows that requirements as expressed right now within oneM2M are not all testable. This analysis has been fed back to the oneM2M Security and Test committees and may lead to a revision of TS003.

Compliance testing will identify what are the covered security requirements. Coverage will be expressed in % and the number of pass and fail tests will be recorded. Regarding exploratory testing, the detected failures will be recorded.

4.2.7.5 Specific Requirements Table 11: requirements related to the Secure IoT platform experiment.

Req. N° Requirement Type Priority Comment GEN7-1 A running

implementation of oneM2M MUST be available online

Infrastructure MUST The first choice is to use MOBIUS platform however, actual implementation of security function is to be checked. The alternative is to use oneM2M.

GEN7-2 A running implementation of FIWARE MUST be available online

Infrastructure MUST

GEN7-3 The security requirements MUST be identified

Set-up MUST For all considered platforms. This is the basis to develop a test objectives charter

GEN7-4 A priority list within security topic SHOULD be provided

Set-up SHOULD A possibility that the work on oneM2M security requirements will allow to prioritize the lists

GEN7-5 A test model of the considered platform MUST be available

Set-up MUST Creation of an MBT model for test generation based on the defined scope. It will include the definition of test patterns for the considered vulnerabilities (from oneM2M perspective)

52

GEN7-6 A test harness MUST connect the test environment to the device under test

Control MUST The test harness is necessary to automate test execution and ensure repeatability of the study

GEN7-7 The execution results MUST be stored

Analysis MUST

GEN7-8 The collected data MUST be analysed.

Analysis MUST

53

5 Security analysis

The 7 targeted ARMOUR experimentations are reminded below

• EXP 1. Bootstrapping and group sharing procedures

• EXP 2. Sensor node code hashing • EXP 3. Secured bootstrapping/join

for the IoT • EXP 4. Secured OS / Over the air

updates

• EXP 5. Trust aware wireless sensors networks routing

• EXP 6. Secure IoT Service Discovery

• EXP 7. Secure IoT platform

The mapping of targeted vulnerabilities identified by these 7 experiments over the ARMOUR security reference framework is provided in Table 12. These will be used as an input to the deliverable D2.1 which will aim at defining associated test patterns.

Table 12: mapping of ARMOUR security vulnerabilities over experiments

Id Title Experiment

1 2 3 4 5 6 7 Σ

V1 Discovery of Long-Term Service-Layer Keys Stored in M2M Devices or M2M Gateways X X X 4

V2 Deletion of Long-Term Service-Layer Keys stored in M2M Devices or M2M Gateways X X 2

V3 Replacement of Long-Term Service-Layer Keys stored in M2M Devices or M2M Gateways X X 2

V4 Discovery of Long-Term Service-Layer Keys stored in M2M Infrastructure X 1

V5 Deletion of Long-Term Service-Layer Keys stored in M2M Infrastructure equipment X 1

V6 Discovery of sensitive Data in M2M Devices or M2M Gateways X X 2

V7 General Eavesdropping on M2M Service-Layer Messaging between Entities X 1

V8 Alteration of M2M Service-Layer Messaging between Entities X X X X X X 6 V9 Replay of M2M Service-Layer Messaging between Entities X X X X X X 6

V10 Unauthorized or corrupted Applications or Software in M2M Devices/Gateways X X X X X 5

V11 M2M System Interdependencies Threats and cascading Impacts 0 V12 M2M Security Context Awareness X 1 V13 Eaves Dropping/Man in the Middle Attack X X X X X 5 V14 Transfer of keys via independent security element X X X 3 V15 Buffer Overflow 0 V16 Injection X 1 V17 Session Management and Broken Authentication X X 2 V18 Security Misconfiguration X X 2 V19 Insecure Cryptographic Storage X X X 3 V20 Invalid Input Data X 1 V21 Cross Scripting 0

54

Most of the vulnerabilities are getting covered, except from V11, V15 and V21.

• V11 relates to complex interaction of M2M systems among them. These are advanced deployment features not foreseen in the short term and not included within ARMOUR experiments which is firstly looking at security issues at a more atomic level.

• V15 is not targeted during the first phase of the project but may later be investigated at device level.

• V21, cross-scripting, is about injecting executable code within web pages however no webpages will be used within ARMOUR experiments. Other types of injection are covered within V16.

55

6 Requirements analysis

The requirements collected from the ARMOUR experiments have been analysed and aggregated so to end up with a list of 30 requirements provided in Table 13. These requirements will be used as a basis for test framework set-up (WP2) as well as testbeds provisioning (WP3).

Table 13: Aggregated experiments requirements

Req. N° Requirement Type Priority EXP Req Id

GEN1 CoAP Infrastructure MUST GEN1-1 GEN5-4 GEN6-3

GEN2 Gateway must also support TLS/DTLS Set-up MUST

GEN1-2 GEN1-4 GEN6-4

GEN3 HTTP Set-up MAY GEN1-3

GEN4 Sensors should be made available Infrastructure MUST GEN1-5

GEN5 Gateway should be made available Infrastructure MUST GEN1-6

GEN6 XACML Infrastructure MUST GEN1-7

GEN7 It must be possible to monitor the power consumption of devices during experiment

Analysis MUST GEN2-1

GEN8 It should be possible to configure sniffers Infrastructure SHOULD

GEN2-2 GEN3-1 GEN4-1 GEN5-3 GEN6-2

GEN9 It should be possible to imposed communication paths Control SHOULD GEN2-3

GEN11 inject malicious packets / replay / evil nodes Control SHOULD GEN3-3

GEN4-3

GEN12 Node supporting OpenWSN / 6TiSCH / COSE Set-up MUST GEN3-4

GEN4-4

GEN13 Node supporting RIOT / OTA Set-up MUST GEN3-5 GEN4-5

GEN14 Node supporting RIOT / OTA / COSE Set-up MAY GEN3-6

GEN4-6

GEN15 Node supporting OpenWSN / 6TiSCH / COSE / OTA Set-up MAY GEN3-7

GEN4-7

GEN16 Motes must support at least TinyOS and ContikiOS protocol stack

Set-up MUST GEN5-1 GEN6-1

GEN17 Experiment should include mobile motes Infrastructure SHOULD GEN5-2

GEN18 Remote access to motes for OTA (re)programming Control MUST GEN5-5

GEN6-5

GEN19 The programmer may require access to debugger Analysis MAY GEN5-6

GEN6-6

GEN20 Infrastructure must support e2e IPv6 connectivity during set-up Set-up MUST GEN5-7

GEN6-7

GEN21 Gateway should suport IPv6-IPv4 translation Control SHOULD GEN6-8

GEN22 The infrastructure must support PSK, HMAC-SHA256, AES-128, Set-up MUST GEN6-9

56

GEN23 A running implementation of oneM2M MUST be available online

Infrastructure MUST GEN7-1

GEN24 A running implementation of FIWARE MUST be available online

Infrastructure MUST GEN7-2

GEN25 The security requirements MUST be identified Set-up MUST GEN7-3

GEN26 A priority list within security topic SHOULD be provided Set-up SHOULD GEN7-4

GEN27 A test model of the considered platform MUST be available Set-up MUST GEN7-5

GEN28 A test harness MUST connect the test environment to the device under test

Control MUST GEN7-6

GEN29 The execution results MUST be stored Analysis MUST GEN7-7

GEN30 The collected data MUST be analysed. Analysis MUST GEN7-8

57

7 Conclusion

The deliverable D1.1 initiates and frames the ARMOUR work. For that purpose, it first defines a reference security framework for the project, based on on-going standardisation initiatives. The oneM2M alliance has made a detailed and use case based analysis of security threats and its analysis has been used as main inspiration in the context of the project. This framework is also discussed in the context of security labelling for IoT. The ARMOUR security reference framework has then been expressed as a list of 21 vulnerability patterns.

The seven experiments planned within ARMOUR have then been described, by relating their intended focus to the vulnerability patterns and describing the solutions to be experimented to protect against the identified vulnerabilities and test the actual protection. From the descriptions, general requirements from experimenters have been identified and aggregated within a list of 30 general requirements related to experiments.

This work paves the way to the following deliverables:

• D2.1 “Generic test patterns and test models for IoT security testing” which derives test patterns from the vulnerability patterns

• D3.3 “Integrated ARMOUR experimentation services with FIT IoT-LAB testbed” which will be built upon collected requirements to provide an integration plan.

58

8 Annexes

8.1 References [1] Future Internet Research and Experimentation (FIRE). http://www.ict-fire.eu. [2] RASEN (Compositional Risk Assessment and Security Testing of Networked Systems),

http://www.rasenproject.eu/ [3] FIT IoT Lab, https://www.iot-lab.info/ [4] Common Vulnerabilities and Exposures, https://cve.mitre.org/ [5] IETF, “Key words for use in RFCs to Indicate Requirement Levels”, RFC2119 [6] K. Pohl and C. Rupp, “Requirements engineering fundamentals: a study guide for the certified

professional for requirements engineering exam”, ISBN 978-1-933952-81-9, 2011. [7] https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Attack_Surface_Ar

eas [8] http://www.iot-vienna.at/global-iot-day-

event/2015/lib/exe/fetch.php?media=talks:gieshofer_juergen:owasp_iot_top10.pdf [9] https://www.owasp.org/index.php/Perform_security_analysis_of_system_requirements_and_design_

(threat_modeling) [10] https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology [11] oneM2M white paper, January 2015, http://www.onem2m.org/images/files/oneM2M-whitepaper-

January-2015.pdf [12] http://www.onem2m.org/images/files/deliverables/TS-0001-Functional_Architecture-V1_6_1.pdf [13] GSMA Security Framework CLP11, February, 2016 [14] http://csrc.nist.gov/groups/SMA/fisma/framework.html [15] http://www.cert.org/resilience/products-services/octave/ [16] Global Compliance assessment Forum (GCF). http://www.globalcertificationforum.org/ [17] Murdoch, S. J., Bond, M., & Anderson, R. (2012). How certification systems fail: Lessons from the

Ware report. IEEE Security & Privacy, 10(6), 40-44. [18] Anderson, R., Böhme, R., Clayton, R., & Moore, T. (2008). Security economics and the internal

market. Study commissioned by ENISA. [19] Anderson, R., & Fuloria, S. (2009, September). Certification and evaluation: A security economics

perspective. In Emerging Technologies & Factory Automation, 2009. ETFA 2009. IEEE Conference on (pp. 1-7). IEEE.

[20] NIST Special Publication 800-37, "Guide for Applying the Risk Management Framework to Federal Information Systems. http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

[21] Case Studies for the Cyber-Security of Industrial Automation and Control Systems IACS CASE STUDIES https://erncip-project.jrc.ec.europa.eu/networks/tgs/ics-use-cases.

[22] Common Criteria. http://www.commoncriteriaportal.org/ [23] “OneM2M security solutions”, oneM2M-TR-0008-Security-V1.0.0, 2014 [24] “Internet of Things Top Ten”, OWASP,

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project, 2014 [25] Open & Agile Smart cities, http://www.oascities.org/open-and-agile-smart-cities/ [26] oneM2M white paper, January 2015, http://www.onem2m.org/images/files/oneM2M-whitepaper-

January-2015.pdf [27] International Software Testing Qualification board (ISQB), Model-Based Tester Extension Syllabus,

2016, http://www.istqb.org/downloads/syllabi/model-based-tester-extension-syllabus.html [28] M. Utting & B. Legeard (2007). Practical model-based testing - A tools approach, Elsevier

http://www.ict-fire.eu/

http://www.rasenproject.eu/

https://www.iot-lab.info/

https://cve.mitre.org/

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Attack_Surface_Areas

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Attack_Surface_Areas

http://www.iot-vienna.at/global-iot-day-event/2015/lib/exe/fetch.php?media=talks:gieshofer_juergen:owasp_iot_top10.pdf

http://www.iot-vienna.at/global-iot-day-event/2015/lib/exe/fetch.php?media=talks:gieshofer_juergen:owasp_iot_top10.pdf

https://www.owasp.org/index.php/Perform_security_analysis_of_system_requirements_and_design_(threat_modeling)

https://www.owasp.org/index.php/Perform_security_analysis_of_system_requirements_and_design_(threat_modeling)

https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

http://www.onem2m.org/images/files/oneM2M-whitepaper-January-2015.pdf


http://www.onem2m.org/images/files/deliverables/TS-0001-Functional_Architecture-V1_6_1.pdf

http://csrc.nist.gov/groups/SMA/fisma/framework.html

http://www.globalcertificationforum.org/

http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

https://erncip-project.jrc.ec.europa.eu/networks/tgs/ics-use-cases

http://www.commoncriteriaportal.org/

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project



http://www.istqb.org/downloads/syllabi/model-based-tester-extension-syllabus.html

59

8.2 Vulnerability patterns

This section lists vulnerability patterns identified within the Project. These patterns have been created from the one identified within the oneM2M initiative [23] and completed to cover ARMOUR use cases.

Discovery of Long-Term Service-Layer Keys Stored in M2M Devices or M2M Gateways

V1

Vulnerability pattern summary

Long-term service-layer keys are discovered while they are stored in M2M Devices or M2M Gateways and are copied.


Long-term service-layer keys are stored within the M2M Device or M2M Gateway. Those keys are discovered and copied by unauthorized entities and used for illegitimate purposes. Discovery of stored long term service-layer keys may be achieved e.g. by monitoring internal processes (e.g. by Differential Power Analysis) or by reading the contents of memory of the M2M Device or M2M Gateway (by hardware probing or by use of local management commands).


Devices and gateways


Discovery of stored keys may be achieved by monitoring internal processes (e.g. by Differential Power Analysis) or by reading the contents of memory.

Consequences Copying keys to impersonate devices, gateways or M2M infrastructure equipment (discovery), denial of service attack (deletion) or allowing illegitimate operation (replacement)

Example - Relationships V13

oneM2M thread ID1 [23]

Deletion of Long-Term Service-Layer Keys stored in M2M Devices or M2M Gateways

V2


Long-term service-layer keys are deleted or deprecated while they are stored in M2M Devices or M2M Gateways


Long-term service-layer keys are deleted or deprecated. This may be achieved by use of management commands (including impersonation of a system Manager) or by removal of the HSM if present and if removable. This attack may be perpetrated against the key-storage functions of M2M Devices or M2M Gateways.




Deletion of stored keys may be achieved by use of management commands (including impersonation of a system manager)

Consequences Copying keys to impersonate devices, gateways or M2M infrastructure equipment (discovery), denial of service attack (deletion) or allowing illegitimate operation (replacement)



60

Replacement of Long-Term Service-Layer Keys stored in M2M Devices or M2M Gateways

V3


Long-term service-layer keys are replaced while they are stored in M2M Devices or M2M Gateways


Long-term service-layer keys are replaced while they are stored in M2M Devices or M2M Gateways, in order to modify its operation. The attack may be achieved by use of management commands (including impersonation of a system manager) or by removal of the HSM if present and if removable. This attack may be perpetrated against the key-storage functions of M2M Devices



Timing of introduction Replacement of stored keys may be achieved by use of management commands (including impersonation of a system manager)

Consequences Copying keys to impersonate sensors, gateways or M2M infrastructure equipment (discovery), denial of service attack (deletion) or allowing illegitimate operation (replacement)



Discovery of Long-Term Service-Layer Keys stored in M2M Infrastructure

V4


Long-term service-layer keys are discovered while they are stored in the M2M infrastructure equipment (e.g. equipment holding network CSE or security server) and are copied.


Discovery may be achieved e.g. by the monitoring of internal processes, or by reading the contents of memory locations. The methods of attack include remote hacking and illicit use of management or maintenance interfaces.


Any component of the infrastructure (AAA server, Attribute Authority, Capability Manager, PDP and Pub/Sub server)


Replacement of stored keys may be achieved by use of management commands (including impersonation of a system manager)

Consequences Copied keys may be used to impersonate M2M infrastructure equipment. Example Relationships V13


Deletion of Long-Term Service-Layer Keys stored in M2M Infrastructure equipment

V5


Long-term service-layer keys are deleted or deprecated while they are stored in the M2M infrastructure equipment (e.g. equipment holding network CSE or security server).


Long-term service-layer keys may be deleted or deprecated by use of management commands (including impersonation of a System Administrator).


Any component of the infrastructure (AAA server, Attribute Authority, Capability Manager, PDP and Pub/Sub server)


Replacement of stored keys may be achieved by use of management commands (including impersonation of a system manager)

Consequences Deletion of keys in the infrastructure equipment prevents proper operation and may lead to denial of service. Example Relationships V13


61

Discovery of sensitive Data in M2M Devices or M2M Gateways V6 Vulnerability pattern summary

Sensitive data is discovered while used during the execution of sensitive functions in M2M Devices or M2M Gateways and are copied.


Sensitive data such as long-term service-layer keys are used during the execution of sensitive function within the M2M Device or M2M Gateway and exposed. Sensitive data is then copied by unauthorized entities and used for illegitimate purposes.



Consequences Copied sensitive data such as key material may be used to compromise M2M System security. Example Relationships oneM2M thread ID6 [23]

General Eavesdropping on M2M Service-Layer Messaging between Entities

V7


General Eavesdropping on M2M Service-Layer Messaging Between Entities


By eavesdropping on M2M Service Layer messages between components in the M2M Service Provider's Domain, M2M Devices and M2M Gateways, confidential or private information may be discovered. This excludes the use of eavesdropping to discover or infer the value of keys, which is covered elsewhere in the present document.



Consequences Effect on stakeholders(s): significant effect upon the M2M Service Provider if the users find out about the loss of privacy and if it can be blamed on this attack

Example Relationships oneM2M thread ID7 [23]

Alteration of M2M Service-Layer Messaging between Entities V8 Vulnerability pattern summary

Alteration of M2M Service-Layer Messaging Between Entities


By altering M2M Service Layer messages between components in the M2M Service Provider's Domain, M2M Devices and M2M Gateways, the attacker may deceive or defraud the M2M Service Provider or other stakeholders.


Devices, gateways and any component of infrastructure (AAA server, Attribute Authority, Capability Manager, PDP and Pub/Sub server)


At any time of communication, the attacker may deceive or defraud the service provider or other stakeholders by altering messages between devices

Consequences Effect on stakeholders(s): couldcause a wide-scale attack against Devices or Gateway communications Example A legitimate wireless communication module with unique id (e.g. MAC address) is used by attacker Relationships oneM2M thread ID8 [23]

62

Replay of M2M Service-Layer Messaging between Entities V9 Vulnerability pattern summary

Replay of M2M Service-Layer Messaging Between Entities


By repeating all or portions of previous M2M Service Layer messages between components in the M2M Service Provider's Domain, M2M Devices and M2M Gateways, the attacker may deceive or defraud the M2M Service Provider or other stakeholders.




At any time of communication, the attacker may deceive or defraud the service provider or other stakeholders by repeating all or portions of previous messages between devices

Consequences Effect on stakeholders(s): could cause a wide-scale attack against Devices or Gateway communications. Example Relationships oneM2M thread ID9 [23]

Unauthorized or corrupted Applications or Software in M2M Devices/Gateways

V10


Unauthorised or Corrupted Application and Service-Layer Software in M2M Devices/Gateways


This attack may be used to: • commit fraud, e.g. by the incorrect reporting of energy consumption; • cause a breach of privacy by obtaining and reporting confidential information to the attacker; cause the disclosure of sensitive data such as cryptographic keys or other credentials; • prevent operation of the affected M2M Devices/Gateways. The attack may be perpetrated locally or by illicit use of remote management functions.




The attack may be perpetrated locally or by illicit use of remote management functions

Consequences An attacker installs unauthorised M2M Service-layer software or modifies authorised software functions in M2M Devices or M2M Gateways


M2M System Interdependencies Threats and cascading Impacts V11 Vulnerability pattern summary

M2M System interdependencies threats and cascading impacts


While M2M endpoints and M2M Gateways might be dedicated to specific M2M Services, M2M Systems as a whole will frequently share resources with a variety of other un-related systems and applications.



Consequences Underlying systems and resources may impose many forms of interdependency with the M2M Application, M2M Device / Gateway or M2M Infrastructure which is not apparent during period of normal operation.


63

M2M Security Context Awareness V12 Vulnerability pattern summary

Context-awareness


If the provided Security Level is sufficient and appropriate depends on the use case and the context of the operation. Keeping the security level static for all use cases may lead to inefficient usage of resources (in terms or processor, memory, network, operationally and financially).



Consequences A lack of context awareness for M2M endpoints, gateways and applications may increase the risks associated with resource exhaustion and under provisioning, triggering service impacts or outages.


Eaves Dropping/Man in the Middle Attack V13 Vulnerability pattern summary

Eaves Dropping/Man In the Middle Attack


The primary difficulty lies in monitoring the proper network’s traffic while users are accessing the vulnerable site. Detecting basic flaws is easy. Just observe the site’s network traffic. More subtle flaws require inspecting the design of the application and the server configuration. The attack exploits lack of security protection while data is in transit, or vulnerabilities in the protocol that was chosen to protect the communication pipe




The attack exploits lack of security protection while data is in transit, or vulnerabilities in the protocol that was chosen to protect the communication pipe

Consequences Eaves Dropping/Man In the Middle Attack: keys and other sensitive information can be discovered by eavesdropping on messages at the transport layer

Example Relationships V1, V4


Transfer of keys via independent security element V14 Vulnerability pattern summary

Transfer of keys via independent security element


The attack is carried out by an attacker who gains unauthorized possession of a set of viable keys and credentials by removing them from a legitimate M2M Device. The attacker will then use the removed keys and credentials in different, possibly unauthorized M2M Devices. The M2M Devices may attach to a network and consume non M2M network services, in which the charge will be passed to a legitimate M2M User. Additionally, a denial of service to the legitimate user may occur when the unauthorized M2M Device is online, the unauthorized M2M Device may use legitimate M2M Services, though the cost is passed on to the legitimate user.


Devices, Provisioning servers


Devices can be subject to physical exploitation at any time

Consequences The attack is carried out by an attacker who gains unauthorized possession of a set of viable keys and credentials by removing them from a legitimate M2M Device.

Example A legitimate wireless communication module with unique id (e.g. MAC address) is used by attacker Relationships V19


64

Buffer Overflow V15 Vulnerability pattern summary

Buffer Overflow


Buffers of data + ‘N’ are passed through an API where it is known that the API is designed to have length constraints. The N bytes overflow into an area that was being utilized by other storage (heap overflow) or precipitates the return address to be corrupt (stack overflow). Stack overflows are indicated by the return code jumping to a random location, and as a consequence, incorrect code is executed and may change local data (rights of code or a file)



Consequences Buffers of data + ‘N’ are passed through an API where it is known that the API is designed to have length constraints. The N bytes overflow into an area that was being utilized by other storage (heap overflow) or precipitates the return address to be corrupt (stack overflow). Stack overflows are indicated by the return code jumping to a random location, and as a consequence, incorrect code is executed and may change local data (rights of code or a file)


Injection V16 Vulnerability pattern summary

Injection


Attacker sends simple text-based attacks that exploit the syntax of the targeted interpreter. Almost any source of data can be an injection vector, including internal sources. Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing.



Consequences Send inappropriate queries to the application-level server that will exploit vulnerabilities of the query interpreter in order to gain un-authorized access.


Session Management and Broken Authentication V17 Vulnerability pattern summary

Session Management and Broken Authentication


Consider anonymous external attackers, as well as users with their own accounts, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions. Exploitation spoof this type is of average difficulty, Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users.




The attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users

Consequences Custom session and authentication schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question and account update allowing the attacker to impersonate other entity

Example Relationships V18


65

Security Misconfiguration V18 Vulnerability pattern summary

Security Misconfiguration


Consider anonymous external attackers as well as users with their own accounts that may attempt to compromise the M2M System. Also consider insiders wanting to disguise their actions. Easy to exploit, attacker accesses default accounts, unused pages, un-patched flaws, unprotected files and directories, etc. to gain unauthorized access to or knowledge of the M2M System.




The attacker decides to access default accounts, unused pages, unpatched flaws, unprotected files and directories, etc.

Consequences Attacker accesses default accounts, unused pages, un-patched flaws, unprotected files and directories, etc. to gain unauthorized access to or knowledge of the M2M System

Example Relationships V17


Insecure Cryptographic Storage V19 Vulnerability pattern summary

Insecure Cryptographic Storage


Attackers typically don’t break the cryptography. They break something else, such as find keys, get cleartext copies of data, or access data via channels that automatically decrypt. The most common flaw in this area is simply not encrypting data that deserves encryption. When encryption is employed, unsafe key generation and storage, not rotating keys, and weak algorithm usage is common. Use of weak or unsalted hashes to protect passwords is also common. External attackers have difficulty detecting such flaws due to limited access. They usually must exploit something else first to gain the needed access.




At any time of communication, the attacker decides to break something, such as find keys, get cleartext copies of data, or access data via channels that automatically decrypt

Consequences The most common flaw in this area is simply not encrypting data that deserves encryption. Example Relationships oneM2M thread ID20 [23]

Invalid Input Data V20 Vulnerability pattern summary

Invalid Input Data


Attackers can inject specific exploits, including buffer overflows, SQL injection attacks, and cross site scripting code to gain control over vulnerable machines. An attacker may be able to impose a Denial of Service, bypass authentication, access unintended functionality, execute remote code, steal data and escalate privileges. While some input validation vulnerabilities may not allow exploitation for remote access, they might still be exploited to cause a crash or a DoS attack.



Consequences Input data validation is used to ensure that the content provided to an application does not grant an attacker access to unintended functionality or privilege escalation


66

Cross Scripting V21 Vulnerability pattern summary

Cross Scripting


Cross-site scripting takes advantage of Web servers that return dynamically generated Web pages or allow users to post viewable content to execute arbitrary HTML and active content such as JavaScript, ActiveX, and VBScript on a remote machine that is browsing the site within the context of a client-server session



Consequences Cross Scripting allows attackers to inject code into the Web pages generated by the vulnerable Web application Example Relationships oneM2M thread ID22 [23]

8.3 oneM2M security requirements analysis

Prior to determining what to test it is essential to identify the requirements to be tested. In this respect oneM2M report TS-0003 does not have an explicit requirements catalogue and Table 14 below is an initial attempt to build one. This has been constructed by extracting text from TS-0003 by making a simple search for mandates (i.e. sentences containing "shall" or ''shall not" as defined in clause 4 of the TS and the referred to oneM2M Drafting Rules).

It is suggested that not all of the resultant requirements catalogued can be tested and an indication of the "testability" of each requirement is given in the table.

This analysis has been contributed to oneM2M technical plenary #23 in May 2016, under reference TST-2016-0091R01-Test_Suite_Structure_and_Test_Purposes_from_TS-0003-V1_4_2, to serve as a basis for security tests development in oneM2M.

Table 14: identification of oneM2M security requirements

67

Req_no Text Source in document

TS-0003V1.4.2

Comment Test Pattern to be defined

TS-0003-1

The security administration component shall enable administration of all sensitive resources (data and functions) and shall also allow configuration and extension of Security services itself 5.1

Not testable without explicit specification of

the protocol and method of administration.

Similarly conditions of extension not explicitly

defined here.

No

TS-0003-2

The Secure Environment within the CSE is accessed via the Secure Environment Abstraction layer and shall hold all sensitive resources 5.1

Not testable without explicit specification of

"all sensitive resources" and not clear if any

"sensitive resource" can be held outside the SE.

No

TS-0003-3 Prior to authorization mutual authentication between the originator CSE or AE and hosting CSE shall be performed 5.1.2

Needs to specify the mutual authentication

procedure. Not testable in this formulation.

However a test purpose for verification of pre-

conditions is proposed.

Yes. Will form a precondition

(a with statement in

TPLan)

TS-0003-4

A Plug-in associated to the type of Secure Environment shall provide physical/logical connectivity to the secure environment 5.2.2

This is a general architectural desire and doesn't actually state

how the connectivity is provided

No

TS-0003-5 The Secure Environment Abstraction Layer shall also be accessible on the Service Layer. 5.2.2

This extends the general requirement of TS-0003-5 but doesn't have any

specific state or protocol to be evaluated.

No

TS-0003-6

This is the purpose of the Security Association Establishment procedure, which shall take place before execution of the service related procedures specified in oneM2M TS-0001 [] for the corresponding reference point 6.1.2.2.1

TS-0001 specifies the service related

procedures. This is a general purpose

statement that does not identify any specific

capability to be tested.

No

TS-0003-7

On the Mca and Mcc reference points, security association establishment between a field domain AE or CSE, respectively, and an IN-CSE is mandatory 6.1.2.2.1

Need to be more explicit in the capabilities established by the

security association. Not testable in this

formulation.

Yes. Will form a precondition

(a with statement in

TPLan)

NOTE: The phrasing here ("is mandatory") implies a requirement but the actual requirement is not specified in a testable way. TS- On the Mcc' reference point, security association establishment between IN-CSE and IN-CSE is mandatory 6.1.2.2.1 Need to be more explicit in the Yes. Will form

68

0003-8 capabilities established by the security association. Not testable in this formulation.

a precondition (a with statement in TPLan)

NOTE: The phrasing here ("is mandatory") implies a requirement but the actual requirement is not specified in a testable way.

TS-0003-9

Once an AE or CSE has been granted access to M2M services, the Access Control procedure specified in clause 7 of the present document shall be executed before accessing an M2M resource, as specified in oneM2M TS-0001 []

6.1.2.2.2

TS-0001 specifies the resources. Clause 7 only specifies (in part) the access control policy using a model based on XACML Policy Enforcement. The policies are not defined. The core requirements for RBAC are stated in clause 9.4 of TR-0008.

TS-0003-10

The Security Administration service shall provide functions to manage the Security functions, resources and attributes. 6.2.3 This is visible via the API but does not

specify how the access is provisioned No

TS-0003-11

This {Security Administration service} shall include management of resources provided via the secure environment 6.2.3 As above No

TS-0003-12

Remote security administration differs from standard device management by the requirement that the secure channel established with the administration server shall have its endpoint in the Secure Environment of the M2M Node

6.2.3.2 It is not clear how the endpoint of the secure channel can be identified as being in the secure environment.

No

TS-0003-13 Sensitive Functions shall include "Secure Storage" 6.2.5 No

TS-0003-14 This service shall provide AEs and CSEs with access to Sensitive Functions of the SE. 6.2.5.1 This is an architectural constraint. No

TS-0003-15

This service shall provide AEs and CSEs with access to the secure storage capability of the SE. Data securely stored by the AE or CSE shall only be accessible through the Security API and by authorized entities. Secure Storage should be managed by the Secure Environment. Stored data shall be associated with the entity owning the data, i.e. the entity that requested the data to be stored within the secure storage.

6.2.5.2

Multiple requirements are stated here. The first requirement implies all data request are intercepted and access control policy applied. This is extended by the second requirement that data is linked (by meta data that is not defined) to the owning entity

No

TS-0003-16

M2M Master Credentials, used to mutually authenticate CSEs/AEs before granting them access to M2M services, shall be securely stored in a specific infrastructure functionality named M2M Authentication Function (MAF).

6.2.6

It is not clear if this requirement to store data securely can be verified at an external point of observation and control. It is a requirement set for trust enablement within the MAF that a penetration test may test as negative but not not prove as positive

No

TS-0003-17

The security sensitive data and security functions contained in M2M field domain nodes shall be protected from unauthorized access or alteration, as determined by risk analysis. Sensitive data and functions include security credentials and algorithms that manipulate them. The purpose of the Secure Environment is to provide the required protection level (see Table 6.3.1-1) and isolation of security sensitive data and functions within an M2M node. This is especially critical for M2M Nodes that can be remotely or physically accessed by potential attackers.

6.3.1

Leads to the requirement to build an access control framework. Not specifcally testable in this formulation. Note that the risk analysis has been performed and documented in TR-0008.

No

TS-0003-18

There is no assumption made on the particular implementation of the Secure Environment. A SE may be implemented as an independent HW Security Element or as an integrated SW function. Each Secure Environment shall be associated with one certain Security Level depending on the particular implementation of the SE. Different Secure Environments may provide different Security Levels and protection levels as indicated in table 6.3.1-1.

6.3.1 Not clear where the association can be interorrogated. No

69

TS-0003-19 There shall be at least one Secure Environment, however there may be multiple. 6.3.1 Not clear where the existence of a

security environment can be interrogated No

TS-0003-20

For case where an AE initiates a new registration request to a CSE and has no preference for an assigned AE-ID value, the fr parameter shall not be sent in the request. All other requests shall have the fr parameter present in the request.

7.1.2 Syntax and semantics testing required to cover this. Yes

TS-0003-21

The accessControlTimeWindow parameter represents a list of elements that comply to the extended crontab syntax as defined in clause 7.3.8 of oneM2M TS-0004 [4]. It allows definition of periodically recurring time intervals at which access shall be granted, when the rq_time parameter associated with the access request message falls into such interval.

7.1.5 Syntax and semantics testing required to cover this.

Yes Tests for TS-0004 shall take precedence.

TS-0003-22

When the Registrar CSE receives a request,the Registrar CSE shall perform the following procedure.

0. Security association establishment is performed.

1. The AE sends a request to Hosting CSE via ist Registrar CSE (Hosting CSE is not represented on this figure and can either be the Registrar CSE or another CSE).

2. The Registrar CSE checks if the value in the From parameter is the same as the ID associated in security association.

3. If the value is not the same, the Registrar CSE sends a response with an impersonation error response code.

4. The Registrar CSE performs procedures specified in clause 8.2 of oneM2M TS-0001 []. Depending on the number of Transit CSEs, the Registrar CSE either processes the request or forwards it to the Hosting CSE or to another Transit CSE.

7.2 This is a protocol test. Tests for both positive and negative behaviour are required.

Yes

TS-0003-23

A FQDN certificate shall be used to authenticate an M2M Enrolment Function to an Enrolee during a Bootstrap Enrolment Handshake phase in a Certificate-Based Remote Security Provisioning Framework.

8.1.2.1 Specialised use of certificate. No

TS-0003-24

If an entity is to authenticate another entity using a device certificate, CSE-ID certificate, AE-ID certificate or FQDN certificate, then the entity shall perform basic path validation (section 6.1of IETF RFC 5280 [34]) as part of verifying the other entity's certificate (see clause 8.1.2.4 "Certificate Verification").

8.1.2.2

Verifies compliance with syntax and structure of RFC5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile)

No

TS-0003-25

CA certificates shall include the name constraint extensions (clause 4.2.1.10 "Name Constraints" of IETF RFC 5280 [34]) and shall constrain the names (object identifier M2M Device IDs from Annex H "Object Identifier Based M2M Device Identifier" oneM2M TS-0001 [1], public domain name representation of the CSE-ID, Absolute AE-ID or FQDNs) which may be in the subsequent certificate used to authenticate the entity (device certificate, CSE-ID certificate, AE-ID certificate or FQDN certificate respectively).

8.1.2.2

Verifies compliance with syntax and structure of RFC5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile)

Yes. Will form a precondition (a with statement in TPLan)

TS-0003-26

Certificate status verification: In the case of an Infrastructure Domain entity receiving an MEF certificate, the entity shall verify the status of the certificate using a Certificate Revocation List as described in IETF RFC 5280 [34]. oneM2M support for certificate status checking in Field Domain entities requires further study. A mapping of the Online Certificate Status Protocol (OCSP) onto HTTP may be used, as described in Appendix A of IETF RFC 6960 [35], however a mapping of OCSP onto CoAP is not currently defined. Furthermore, OCSP may also not be easily applicable in all environments. An alternative approach may be using the TLS Certificate Status Request extension (section 8 of IETF RFC 6066 [44]; also known as "OCSP stapling") or preferably the Multiple Certificate Status Extension (IETF RFC 6961 [36]), if available.

8.1.2.2 Identifies further study required hence premature to define a test No

70

TS-0003-27

If an entity is to authenticate itself using a Certificate-Based Security Framework, then the entity shall be pre-provisioned with the following information:

• The entity's Private Signing Key.

NOTE: An entity authenticates itself to other entities by proving that it knows the Private Signing Key corresponding to a particular Public Verification Key.

• The entity's Certificate (and if applicable, Certificate Chain) as described in clause 10.1.1 "Certificate Profiles".

• In the case of a CSE-ID certificate the entity shall be configured with the entity's CSE-ID.

• In the case of an AE-ID certificate the entity shall be configured with the entity's AE-ID.

8.1.2.3

Identifies a pre-provisioning requirement that is caputured using the TPLan statements: with { IUT 'condition 1' and 'condition 2' and not ...etc...}

In this case: with { Entity 'having the private signing key' and ('CSE-ID' or 'AE-ID') and 'certificate'}


TS-0003-28

Entity A shall be configured to trust the following information in order to authenticate Entity B using the certificate-Based SAEF:

• An indication of the public key certificate flavour of other Entity B's Certificate (that is, raw public key certificate, device certificate, CSE-ID certificate or AE-ID certificate).

• In the case where Entity B's certificate is a raw public key certificate:

- A public key identifier for the raw public key in the certificate (see clause 10.1.2 "Public Key Identifiers").

• In the case where other Entity B's certificate is an device certificate, CSE-ID certificate or FQDN certificate:

- A Globally unique identifier: The globally unique identifier for the entity which is also present in the subjectAltName extension of the other entity's certificate:

Device Certificate: A globally unique hardware instance identifier (such as the object identifier M2M Device ID in Annex H "Object Identifier Based M2M Device Identifier" oneM2M TS-0001 [that is present in the device certificate.

CSE-ID Certificate: The public domain name representation of the CSE-ID as defined in TS-0001 [1].

- Trust Anchor Information: For the trust anchor certificates of Entity B's certificate chain (see clause 8.1.2.2 "Path Validation and Certificate Status Verification").

8.1.2.4 Preconfiguration information


TS-0003-29

Entity B shall be configured to trust the following information in order to authenticate Entity A using the Certificate-Based SAEF: 8.1.2.4 Preconfiguration information Yes. Will form

a precondition

71

- An indication of the public key certificate flavour of Entity A’s Certificate (that is, raw public

key certificate, device certificate or CSE-ID certificate).

- In the case where Entity A’s certificate is a raw public key certificate:

o A public key identifier for the raw public key in the certificate (see clause 10.1.2 “Public Key Identifiers”).

- In the case where Entity A’s certificate is an device certificate, CSE-ID certificate or AE-ID certificate:

o Trust Anchor Information: for the trust anchor certificate for Entity A’s certificate chain (see clause 8.1.2.2 “Path Validation and Certificate Status Verification”).

(a with statement in TPLan)

TS-0003-30

In order to authenticate the M2M Enrolment Function using the certificate-based RSPF, an Enrolee shall be configured to trust the trust anchor information of the M2M Enrolment Function’s certificate chain.



72

TS-0003-31

An M2M Enrolment Function shall be configured to trust the following information in order to authenticate an Enrolee using the certificate-based RSPF:

- An indication of the public key certificate flavour of Entity B’s Certificate (that is, raw public key certificate or device certificate).

- In the case where the Enrolee’s certificate is a raw public key certificate:

o A public key identifier for the raw public key in the certificate (see clause 10.1.2 “Public Key Identifiers”).

- In the case where the Enrolee’s certificate is an device certificate, CSE-ID certificate or AE-ID certificate:

o A Globally unique identifier: The globally unique identifier which is also present in the subjectAltName extension of the Enrolee’s certificate

Device Certificate: A globally unique hardware instance identifier (such as the object identifier M2M Device ID in Annex H “Object Identifier Based M2M Device Identifier” TS-0001 [1]) that is present in the device certificate.

CSE-ID Certificate: The public domain name representation of the CSE-ID as defined in TS-0001 [1].

AE-ID Certificate: The Absolute AE-ID assigned to the AE.

o Trust Anchor Information: for the trust anchor certification for the Enrolee’s certificate chain (see clause 8.1.2.2 “Path Validation and Certificate Status Verification”).



73

TS-0003-32

If the certificate information configured during the Association Configuration or Bootstrap Instruction Configuration indicates that the other entity's Certificate is a device certificate, CSE-ID certificate, AE-ID certificate or FQDN certificate, then the entity shall perform the following verifications:

The entity shall look for a match between the globally unique identifier described in clause 8.1.2.4 "Information Needed for Certificate Authentication of another Entity" (received during Association Configuration or Bootstrap Instruction Configuration) and the values in the subjectAltName extension of the other entity's Certificate (received during the Security Handshake). If there is not an exact match, then the entity shall abort the (D)TLS handshake.

In the case of device certificate, the globally unique identifier is a globally unique hardware instance identifier (such as the object identifier M2M Device ID in Annex H "Object Identifier Based M2M Device Identifier" oneM2M TS-0001 []. In this case, the notion of a "match" depends on how the globally unique hardware instance identifier may be represented in the subjectAltName extension.

In the case of a CSE-ID certificate, the globally unique identifier is the public domain name representation of the CSE-ID as defined in TS-0001[1], and a match is a FQDN in the subjectAltName extension in the other entity's certificate that is an exact match for the public domain name representation of the CSE-ID.

In the case of an AE-ID certificate, the globally unique identifier is the AE-ID, and a match is a URI in the subjectAltName extension in the other entity's certificate that is an exact match for the Absolute AE-ID.

In the case of an FQDN certificate, the globally unique identifier is the FDQN of the M2M Authentication Function or M2M Enrolment Function, and a match is a URI, FQDN or dNSName in the subjectAltName extension in the other entity's certificate that is an exact match for the FDQN of the M2M Authentication Function or M2M Enrolment Function.

The entity shall perform path validation and certificate status verification using the trust anchor certificate as described in clause 8.1.2.2 "Path Validation and Certificate Status Verification"). If this verification fails, then the entity shall abort the (D)TLS handshake.

8.1.2.5 Takes account of the preconfiguration of the states defined in clause 8.1.2.4 Yes

TS-0003-33

The entities shall validate each other's Certificate before trusting the Public Verification Keys in the Certificate. Within the Security Handshake, entity A creates a digital signature of the session parameters using its private signing key and entity B verifies the digital signature using entity A's public verification key. Then the roles are reversed: entity B creates a digital signature and entity A verifies it. For more details see clause 8.2.2.2.

8.2.1 Contained within the description of Certificate Based SAEF.

No (see against 8.2.2.2)

TS-0003-34

Entity A shall be configured with IdB, the CSE-ID for Entity B. 8.2.1 Preconfiguration information


TS- Otherwise, the CSE-ID or AE-ID(s) shall be made available to Entity B via one of the following approaches. 8.2.1 Preconfiguration information Yes. Will form

74

0003-35 If the Security Association Establishment procedure is facilitated by an M2M

Authentication Function, then the M2M Authentication Function may be provided with the CSE-ID or AE-ID and the M2M Authentication Function may provide this to Entity B at the same time as Kc is provided to Entity B. The M2M Authentication Function could have been provided with the CSE-ID or AE-ID during provisioning, including the case where the M2M Authentication Function is provided with the CSE-ID or AE-ID during remote provisioning by an M2M Enrolment Function (which is similar to the case described in the following bullet).

If the Security Association Establishment procedure uses a Provisioned Symmetric Key which was remotely provisioned to Entity A and Entity B, then the M2M Enrolment Function may provide Entity B with CSE-ID or AE-ID during the Remote Security Provisioning procedure.

If the M2M Service Provider assigns Entity A’s entity identifier(s), then the CSE-ID or AE-ID(s) may be securely configured by the M2M Service Provider to Entity B prior to the Association Security Handshake. For example, the CSE-ID or AE-ID(s) may be configured as part of Credential Configuration or Association Configuration. This specification permits using other mechanisms, with the assumption that the mechanism provides authentication, integrity protection and optionally confidentiality.

• Example 1. If the M2M Service Provider has the opportunity to configure Entity B prior to deployment, then the M2M Service Provider could configure the CSE-ID or AE-ID(s) to Entity B at this time.

• Example 2. A secure remote management protocol could be used to configure Entity B with the CSE-ID or AE-ID(s). However, this is not currently an interoperable feature as there is no standardized management object facilitating this management.

In the case that Entity A is an AE and Entity B is a CSE, the applicable AE-ID(s) may be obtained by retrieving the applicable <serviceSubscribedAppRule> resources which are linked to by the ruleLinks attribute of the Entity B’s <serviceSubscribedNode> on the IN-CSE as described in clause 10.1.1.2.2 “Application Entity Registration procedure” in TS-0001 [1].


TS-0003-36

Credential Configuration: The Provisioned Secure Connection Key (Kpsa) and the corresponding Provisioned Secure Connection Key Identifier, denoted KpsaId, are provisioned to both entities either with pre-provisioning or remote provisioning. The format of KpsaId is defined in clause 10.5 “KpsaId Format”. If Entity A is a CSE, then Entity A shall also be configured with its CSE-ID (not shown in the figure).



TS-0003-37

Credential Configuration: The private keys and certificates for each entity are pre-provisioned as described in clause 8.1.2.3 "Credential Configuration for Certificate-Based Security Frameworks". If Entity A is a CSE, 8.2.2.2 Preconfiguration information Yes. Will form

a precondition

75

then Entity A shall also be configured with its CSE-ID (not shown in the figure).

(a with statement in TPLan)

TS-0003-38

Credential Configuration: The Master Credential (Km) and corresponding Master Credential Identifier (KmId) are either pre-provisioned for Entity A and the MAF or remotely provisioned thanks to Remote Security Provisioning Frameworks described in clause 8.3. The format of KmId is defined in clause 10.6 “KmId Format”. Entity A is also provisioned with the MAF URI to contact during the MAF Handshake. If Entity A is a CSE, then Entity A shall also be configured with its CSE-ID (not shown in the figure).



TS-0003-39

Association Configuration: Entity A and the MAF shall be configured with the information needed for the authentication and identification during MAF Handshake and Association Security Handshake:



TS-0003-40

The MAF returns Kc, Kc Lifetime, and KmId to Entity B. If MAF is configured with CSE-ID or AE-ID for Entity A (see clause 8.2.1 “Overview of Security Association Establishment Frameworks”), then the MAF shall pass this information to Entity B also.

8.2.2.3 The end of the MAF handshake Yes

TS-0003-41

Entity A and Entity B may establish a fresh (D)TLS-PSK handshake using Kc at any time within the Kc Lifetime. Once Kc Lifetime expires, then Entity B shall fail the (D)TLS-PSK handshake, which indicates to Entity B that a fresh MAF Handshake is required.

8.2.2.3 Reinstatement of MAF handshake Yes

TS-0003-42

Provisioned Symmetric Key Association Establishment uses a symmetric key Kpsa and corresponding KpsaId, shared between two entities (Entity A and Entity B), to establish security associations between those two entities (CSE/AEs), as described in clause 8.2.2.1. This symmetric key Kpsa and corresponding KpsaId shall be either pre-provisioned or remotely provisioned to the two CSE/AEs thanks to Security Bootstrap Frameworks.



TS-0003-43

The Master Credential (Km) and corresponding Master Credential Identifier (KmId) shall either be pre-provisioned or remotely provisioned to the CSE/AE and M2M Authentication Function.



TS-0003-44

The Enrolee and M2M Enrolment Function shall validate each other's Certificate before trusting the Public Verification Keys in the Certificate. Within the Security Handshake, the M2M Enrolment Function creates a digital signature of the session parameters using its private signing key and the Enrolee verifies the digital signature using the M2M Enrolment Function's public verification key. Then the roles are reversed: the Enrolee creates a digital signature and the M2M Enrolment Function verifies it. For more details see clause 8.3.2.2.

8.3.1.2 Detail given in 8.3.2.2 No

TS-0003-45

The M2M Enrolment Function authorizes M2M Authentication Function, i.e. the M2M Enrolment Function shall verify whether the requested Enrolee(i.e. KeId associated with an Enrolee) information and credentials can be provisioned to M2M Authentication Function.

8.3.1.2 Detail given in 8.3.2.2 No

TS-0003-46

To share a long term Master Credential (Km) or Provisioned Secure Connection Key (Kpsa) between an Application Service/Middle Node and an Enrolment Target, the M2M Application Service/Middle Node shall perform a successful GBA bootstrapping and derive a NAF key (Ks_(ext/int)_NAF). This NAF key is the Master Credential (Km) or Provisioned Secure Connection Key (Kpsa).

8.3.2.3 Refers to GBA. Thus the GBA test purposes and test cases apply No

TS-0003-47

Bootstrap Instruction Configuration: The Enrolee, the MEF and the Enrolment Target shall be configured with the information needed for authorizing the remote provisioning.

8.3.2.3 Preconfiguration information Yes. Will form a precondition (a with

76

statement in TPLan)

TS-0003-48

The Enrolee shall be configured with the Enrolment Target Identity: identifying the Enrolment Target for which the Enrolee is to be provisioned.



TS-0003-49

The MEF shall be configured with the Enrolee-ID and the Enrolment Target Identity:

- The Enrolment Target Identity: Identifying the Enrolment Target for which the Enrolee (authenticated using the GBA) is to be provisioned.

- The Enrolee's assigned CSE-ID or AE-ID (Enrolee-ID), The M2M Enrolment Function is to provide this entity identity for the Enrolee with the Km or Kpsa to the Enrolment Target, when requested by the Enrolment Target.

- Enrolee's GBA User Security Settings (GUSS) enables indicating if Enrolee is allowed to establish a NAF-specific key with the Enrolment Target or/and if the BSF can distribute a NAF specific key to the Enrolment Target.



TS-0003-50

The Enrolment Key (Ke) shall be the GBA Bootstrapped key (Ks) established during the Bootstrap Enrolment Handshake.

8.3.2.3 Described in 3GPP TS 33.220 and relevant tests from there should apply No

TS-0003-51

The Enrolment Key Identifier (Ke-ID) shall be the Bootstrapping Transaction Identifier ( B-TID) generated during the Bootstrap Enrolment Handshake. 8.3.2.3 Described in 3GPP TS 33.220 and

relevant tests from there should apply No

TS-0003-52

The Enrolee and the Enrolment Target shall establish the Master Credential (Km) or the Provisioned Secure Connection Key (Kpsa) thanks to procedures described in 3GPP TS 33.220 [13] using the Enrolment Key (Ke) as GBA bootstrapped key Ks and the Enrolment Key Identifier (Ke-ID) as B-TID. The Enrolment Target plays the role of a NAF.


TS-0003-53

The Enrolee and the Enrolment Target shall establish NAF-specific key(s) as described in 3GPP TS 33.220 [13]. A key lifetime is associated to the NAF-specific keys. The Enrolment Target also receives the Enrolee's User Security Settings (USS) from the MEF/BSF:

- The Enrolee and the Enrolment Target shall establish NAF-specific key(s) as described in 3GPP TS 33.220 []. A key lifetime is associated to the NAF-specific keys. The Enrolment Target also receives the Enrolee's User Security Settings (USS) from the MEF/BSF:

The FQDN of the NAF, used as input to generate the Ks_(int/ext)_NAF, shall be set as follows:

• In the case where the Enrolment Target is an M2M Authentication Function, then the FQDN of the NAF is set to the FQDN of the M2M Authentication Function.

• In the case where the Enrolment Target is a CSE, then the FQDN of the NAF is set to the public domain name representation of the CSE-ID as defined in TS-0001 [1].


77

In case of GBA_ME, NAF-specific key is Ks_NAF.

In case of GBA_U, NAF-specific keys are Ks_int_NAF and Ks_ext_NAF.

- The Master Credential (Km) ) or the Provisioned Secure Connection Key (Kpsa) shall be the NAF-specific key:

In case of GBA_ME, Km/Kpsa = Ks_NAF.

In case of GBA_U, Km/Kpsa = Ks_int_NAF if HTTP Client application resides in the UICC. Otherwise, Km/Kpsa = Ks_ext_NAF.

- The Enrolee and the Enrolment Target shall set the Master Credential Identifier (Km-Id) or the Provisioned Secure Connection Key Identifier (Kpsa-Id) to the value of KeId.

78

TS-0003-54

Enrolee and Enrolment Target shall perform (D)TLS-PSK handshake (IETF RFC 4279 [15]) with the Master Credential (Km) or Provisioned Secure Connection Key (Kpsa) as Pre-Shared Key in compliance with clause 10.2.2 "TLS and DTLS Ciphersuites for TLS-PSK-Based Security Frameworks". If UICC is used as Secure Environment supporting Remote Security Provisioning, GBA-U with Km/Kpsa = Ks_int_NAF shall be used for authentication and key exchange.


TS-0003-55

Entity B and MAF shall be able to establish mutually-authenticated secure communication. The details are not specified in the present document 9.1.1.1 Details not specificed No

TS-0003-56

Entity B and MAF shall be able to establish mutually-authenticated secure communication. The details are not specified in the present document

9.1.1.2 Details not specified No

TS-0003-57

The Credential Configuration of M2M Authentication Framework shall be achieved through either:

• Business logic of the Stakeholder operating the M2M Authentication Function, and the details are not described in the present document.

• Remote provisioning via one of the Remote Security Provisioning Frameworks in clause 8.3.

9.1.1.2 Test scenarios from 8.3 apply for the second option. Else as not specified can not be verified.

No

TS-0003-58

Mechanisms for Association Configuration of Entity A shall authenticate the configuration source and provide integrity protection for the configured information communicated from the configuration source to the entity. 9.1.2.1.1 Whilst not explicit this is provided by

verification of the signature Yes

TS-0003-59

Mechanisms for Association Configuration of Entity B shall authenticate the configuration source and provide integrity protection for the configured information communicated from the configuration source to the entity. 9.1.2.1.2 Whilst not explicit this is provided by

verification of the signature Yes

TS-0003-60

The Bootstrap Credential Configuration of an Enrolee for the Pre-Provisioned Symmetric Enrolee Key Remote Security Provisioning Framework and Certificate-Based Remote Security Provisioning Framework shall authenticate the configuration source and shall provide confidentiality and integrity protection of the configured information communicated from the configuration source to the secured environment of the Enrolee. The present document does not specify any such mechanisms.

9.2.1.1 Whilst not explicit this is provided by verification of the signature No

TS-0003-61

Mechanisms for Bootstrap Instruction Configuration of Enrolees shall authenticate the configuration source and shall provide at least integrity protection of the configured information communicated from the configuration source to the Enrolee.

9.2.2.1 Whilst not explicit this is provided by verification of the signature No

TS-0003-62

All certificates shall conform to the following profile: • Certificates shall conform to IETF RFC 5280

• The certificate shall include a SubjectPublicKeyInfo that indicates an algorithm of id-ecPublicKey with namedCurves secp256r1 []; this curve is equivalent to the NIST P-256 curve [].

• The public key format shall be uncompressed [].

• The hash algorithm shall be SHA-256.

• The key usage extension shall be included and shall indicate at least digitalSignature.



TS-0003-63

Raw public key certificates shall conform to clause 10.1.1.1 "Common Certificate Details" and IETF RFC 7250 [37]. 10.1.1.2 Preconfiguration information


79

TS-0003-64

Certificates with Certificate Chains shall conform to the following description: • These certificates shall conform to clause 10.1.1.1 "Common Certificate Details".

• Certificates shall be signed with ECDSA using secp256r1, and the signature shall use SHA-256.

• Certificate chains should limit the number of intermediate CA certificates to avoid having a negative impact in constrained environments.



TS-0003-65

Device certificates shall conform to the following description: • Device certificates shall conform to clause 10.1.1.3 "Details Common to the Certificates with

Certificate Chains".

• The subjectAltName extension of device certificates shall include one or more globally unique hardware instance identifiers.

10.1.1.4.1 Preconfiguration information


TS-0003-66

Certificate Authority Certificates in the certificate chain for a device certificate shall conform to the following description:

• These certificates shall conform to clause 10.1.1.3 "Details Common to the Certificates with Certificate Chains".

• Certificate Authority Certificates for device certificates are recommended to use the name constraints extension (see clause 4.2.1.10 "Name Constraints" of IETF RFC 5280 []) to constrain the globally unique hardware instance identifiers in subsequent device certificates in a certification path.

10.1.1.4.2 Preconfiguration information


TS-0003-67

AE-ID certificates and all other certificates in the corresponding certificate chain shall conform to clause 10.1.1.3 "Details Common to Certificates with Certificate Chains".



TS-0003-68

The full URI representation of the AE-ID shall be included in the subjectAltName extension. 10.1.1.5 Refers back to 10.1.1.3.


TS-0003-69

The certificate used to sign the AE-ID certificate shall include nameConstraints satisfied by the hostname part of the full URI representation of the AE-ID.

10.1.1.5 Refers back to 10.1.1.3.


TS-0003-70

AE-ID certificates shall not include wildcards. 10.1.1.5 Refers back to 10.1.1.3.


TS-0003-71

FQDN Certificates and all other certificates in the corresponding certificate chain shall conform to clause 10.1.1.3 "Details Common to Certificates with Certificate Chains".

10.1.1.6 Refers back to 10.1.1.3 Yes. Will form a precondition (a with

80

statement in TPLan)

TS-0003-72

An FQDN Certificate shall include the FQDN of the subject M2M Enrolment Function in the subjectAltName extension.

10.1.1.6 Refers back to 10.1.1.3


TS-0003-73

FQDN Certificates shall not include wildcards. 10.1.1.6 Refers back to 10.1.1.3


TS-0003-74

CSE-ID certificates and all other certificates in the corresponding certificate chain shall conform to clause 10.1.1.3 “Details Common to Certificates with Certificate Chains”.

10.1.1.7 Refers back to 10.1.1.3


TS-0003-75

The subjectAltName extension shall include the public domain name representation of the CSE-ID as defined in TS-0001 [1].

10.1.1.7 Refers back to 10.1.1.3


TS-0003-76

CSE-ID certificates shall not include wildcards. 10.1.1.7 Refers back to 10.1.1.3


TS-0003-77

The public key identifier for a raw public key certificate shall calculated as described in section 2 of IETF RFC 6920 [40] using the SHA-256 hash algorithm. The public key identifier shall be generated using one of the sha-256-120, sha-256-128 or sha-256 hash algorithms specified in IETF RFC 6920 [40].

10.1.2

Whilst this statement contains 2 requirements it really only identifies the 3 allowed variants of the SHA-256 algorithm so is treated as a single precondition.


TS-0003-78

Where TCP payloads are to be secured, TLS v1.2 [5] shall be used. 10.2.1 Preconfiguration information


TS-0003-79

Where UDP payloads are to be secured, DTLS v1.2 [6] shall be used, noting that the DTLS v1.2 ciphersuites are identical to the TLS v1.2 ciphersuites.

10.2.1 Preconfiguration information


TS-0003-80

All implementations shall support the Server Name Indication (SNI) to indicate their authority in the SNI HostName field as defined in section 3 of IETF RFC 6066 [44]. This is needed so that when a host that acts as a virtual server for multiple Authorities receives a new TLS or DTLS connection, it knows which keys to use for the TLS or DTLS session.



TS- (D)TLS Clients on any Node and (D)TLS Servers on MNs shall support at least one of the TLS ciphersuites 10.2.1 Preconfiguration information Yes. Will form

81

0003-81 indicated in clause 10.2.2. “TLS and DTLS Ciphersuites for TLS-PSK-Based Security Frameworks” or 10.2.3 “TLS and DTLS Ciphersuites for Certificate-Based Security Frameworks”.


TS-0003-82

(D)TLS Servers on INs shall support all of the TLS ciphersuites indicated in clause 10.2.2. “TLS and DTLS Ciphersuites for TLS-PSK-Based Security Frameworks” and 10.2.3 “TLS and DTLS Ciphersuites for Certificate-Based Security Frameworks”.



TS-0003-83

The following Security Frameworks:

• Provisioned Symmetric Key Security Association Establishment Framework;

• MAF-Based Security Association Establishment Framework;

• Pre-Shared Key Remote Security Provisioning Framework;

• GBA-Based Remote Security Provisioning Framework;

shall use one of the key exchange algorithms defined in IETF RFC 4279 [15].



TS-0003-84

TLS implementations in entities supporting these security frameworks shall implement at least the following TLS ciphersuite:

• TLS_PSK_WITH_AES_128_CBC_SHA256 (IETF RFC 5487). 10.2.2 Preconfiguration information


TS-0003-85

DTLS implementations supporting these security frameworks shall implement at least the following ciphersuites

• TLS_PSK_WITH_AES_128_CCM_8 (IETF RFC 6655). 10.2.2 Preconfiguration information


TS-0003-86

The following Security Frameworks:

• Certificate-Based Security Association Establishment Framework;

• Certificate-Based Security Bootstrap Framework;

shall use the standard TLS handshake (IETF RFC 5246 [5]) with the ECDHE_ECDSA Key Exchange (IETF RFC 4492 [43]).



TS-0003-87

TLS implementations supporting these security frameworks shall implement at least the following ciphersuite:

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, IETF RFC 5289.



82

TS-0003-88

DTLS implementations supporting these security frameworks shall implement at least the following TLS ciphersuite:

• TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, IETF RFC 7251



TS-0003-89

Implementations supporting these security frameworks shall support authenticating other entities using all available public key certificate flavours (see clause 8.1.2.1 "Public Key Certificate Flavours"):

• Raw public key certificate: using the mechanism specified in IETF RFC 7250 [], Implementation shall support receiving and processing raw public keys compliant with section 9.1.3.2 "Raw Public Key Certificates" in IETF RFC 7252 [].

• All other certificates: X.509 certificates including device hardware identifier. Implementation shall support receiving and processing raw public keys compliant with section 9.1.3.3 "X.509 Certificates" in IETF RFC 7252 [].



TS-0003-90

The following information shall be used when generating Km from Ke: • the value of the Enrolment Key (Ke);

• the M2M Authentication Function Identifier (MAF-ID) shall be encoded to an octet string according to UTF-8 encoding rules as specified in IETF RFC 3629 [] and apply Normalization Form KC (NFKC) as specified in [].



TS-0003-91

The value of Km shall be generated as: Km := HMAC-SHA-256(Ke, "oneM2M Enrolment Key to Master Credential derivation" || MAF-ID),

where HMAC-SHA-256 is defined in IETF RFC 2104 []



TS-0003-92

The following information shall be used when generating Kpsa from Ke: • The value of the Enrolment Key (Ke).

• Enrolee B's CSE-ID or AE-ID (Enrolee-B-ID), which shall be encoded to an octet string according to UTF-8 encoding rules as specified in IETF RFC 3629 [] and apply Normalization Form KC (NFKC) as specified in [].



TS-0003-93

The value of Kpsa shall be generated as: • Kpsa := HMAC-SHA-256(Ke, "oneM2M Enrolment Key to Provisioned Secure Connection Key

derivation" || Enrolee-B-ID); 10.3.3 Preconfiguration information


TS-0003-94

The KeId value shall be formed as: • KeId = base64encode(RelativeKeId)@MEF_FQDN: 10.3.4 Preconfiguration information


TS-0003-95

The KcId value shall be formed as KcId = base64encode(RelativeKcId)@MAF_FQDN, 10.3.5 Preconfiguration information

Yes. Will form a precondition (a with statement in

83

TPLan)

TS-0003-96

The KpsaId shall be of the form KpsaId = Issuer_Relative_KpsaId@Issuer_FQDN 10.5 Preconfiguration information


TS-0003-97

Issuer_Relative_KpsaId is composed of the Roman alphabet, numerals, ‘.’, ‘_’ and ‘-‘ characters. The issuer of KpsaId shall ensure that no two Kpsa have identical Issuer_Relative_KpsaId.

10.5

It is not indicated how the issuer ensures the uniqueness of Issuer_Relative_Kpsaid and it is assumed this is an implementation option (e.g. by enforcing the UNIQUE constraint in a database record)

No

TS-0003-98

The KmId shall be of the form KmId = MAF_RELATIVE_KmId@MAF_FQDN 10.6 Preconfiguration information


TS-0003-99

MAF_RELATIVE_ KmId is composed of the Roman alphabet, numerals, ‘.’, ‘_’ and ‘-‘ characters. The MAF_RELATIVE_KmId is not case sensitive. The MAF shall ensure that no two Km have identical MAF_RELATIVE_ KmID.

10.6

It is not indicated how the issuer ensures the uniqueness of Issuer_Relative_Kpsaid and it is assumed this is an implementation option (e.g. by enforcing the UNIQUE constraint in a database record)

No

TS-0003-100

In case of UICC (SE compliant with ETSI TS 102 671 [23]), OTA mechanisms as specified in [7] and [8], and its extensions [9], [10] for 3GPP underlying networks or [11] and [12] for 3GPP2 underlying networks shall be used to securely administrate the sensitive data of the M2M Service Layer. UICC provides the highest protection level 3 against attacks according the Classification of Protection levels table 6.2.1-1 in clause 6.2.1.

Annex C.1

The underlying network security is not in scope of M2M and the means to achieve security is not public.

No

TS-0003-101

In case the secure environment is implemented as a Trusted Execution Environment (TEE) according to GlobalPlatform [22], remote administration shall be performed according to GlobalPlatform Remote Administration [21]. TEE provides the medium protection level 2 against attacks according the Classification of Protection levels table 6.2.1-1 in clause 6.2.1.

Annex C.3

GlobalPlatform is an option and should be tested independently of M2M. No

TS-0003-102

The support of UICC provisioning of M2M service subscription information shall be indicated in the M2M Service Table for the corresponding M2M Service Subscription as specified in the present annex.

Annex D Preconfiguration information


TS-0003-103

The support of key derivation using GBA that may be used for bootstrapping or security association shall always be indicated in the Service Table of the UICC application of the Access Network Operator supporting the GBA infrastructure.

Annex D Preconfiguration information


TS-0003-104

A common scenario is where an M2M field node holds a UICC application protecting Access Network security credentials, and these credentials are used to derive M2M Service Layer security credentials used for M2M service bootstrapping or security association establishment in the service layer . As these scenarios require a trust agreement between the involved Access Network operator and M2M Service Provider, UICC support for M2M services in such situation shall be handled within the context of the associated Network

Annex D Refers to D.1 No

84

Access application on the UICC. In particular, the UICC support for M2M credentials derivation using GBA shall be indicated within the UICC application of the Access Network operator. This is specified in clause D.1.

TS-0003-105

The storage of M2M information elements in the UICC and the procedures used for communication between the hosting M2M field node and the UICC shall be as specified in the present annex. The present annex uses abbreviations and coding conventions defined in ETSI TS 102 221 [24].

Annex D

This refers to operation of the UICC. In testing if the IUT is equipped with an UICC the testing of the UICC is not part of M2M

No

TS-0003-106

There may be several oneM2M service frameworks (DF1M2M) within the ADF of a single Access Network subscription, in case this Access Network subscription is used by several independent M2M Service subscriptions. The file IDs of the DF1M2M in any ADF shall be listed under the corresponding entry in EFDIR as specified in clause D.1.2.

Annex D.1.1


No

TS-0003-107

The content of any DF1M2M in an Access Network application ADF shall be as specified in clause D.1.3.

Annex D.1.1


No

TS-0003-108

When a UICC Network Access application supports one or more M2M Service subscription, with a DF1M2M, the EFDIR entry corresponding to this UICC Network Access Application shall contain the following M2M related Data Objects:

Annex D.1.2


No

TS-0003-109

There shall be as many oneM2M Service Framework Data Objects as there are M2M Service Subscriptions provisioned in the ADF.

Annex D.1.2


No

TS-0003-110

This EF indicates which optional oneM2M services are available for the corresponding subscription. If a service is not indicated as available in the oneM2M DF, the hosting M2M field node shall not select this service. The presence of this file is mandatory if optional services are provided by the subscription.

Annex D.1.3.1


No

TS-0003-111

The EF shall contain at least one byte. Further bytes may be included, but if the EF includes an optional byte, then it is mandatory for the EF to also contain all bytes before that byte. Other services are possible in the future and will be coded on further bytes in the EF. Coding:

Annex D.1.3.1


No

TS-0003-112

Service available means that the M2M Service Subscription provisioned in the current DF or ADF has the capability to support the service and that the service is available for the user of the M2M Service Subscription. Service not available means that the service shall not be used by the M2M Service Subscription user, even if the M2M Service Subscription has the capability to support the service.

Annex D.1.3.1


No

TS-0003-113

This EF contains the oneM2M Subscription Identifier, M2M-Sub-ID. There shall be only one TLV object within this EF.

Annex D.1.3.2


No

TS-0003-114

The M2M Subscription Identifier value field shall contain the M2M-Sub-ID encoded as specified in oneM2M TS-0004 [4]. The tag value of the oneM2M Subscription Identifier TLV data object shall be '80'.

Annex D.1.3.2


No

TS- This EF contains the oneM2M Service Provider Identifier, M2M-SP-ID, of the M2M Service Provider related Annex This refers to operation of the UICC. In No

85

0003-115

to the subscription in EF1M2MSID. There shall be only one TLV object within this EF.

D.1.3.3 testing if the IUT is equipped with an UICC the testing of the UICC is not part of M2M

TS-0003-116

The M2M-SP-ID Value field shall contain the M2M-SP-ID encoded as specified in TS-0004 [TS0004]. The tag value of the M2M-SP-ID TLV data object shall be '80'.

Annex D.1.3.3


No

TS-0003-117

This EF contains the M2M-Node-ID supporting the local CSE. It may be used to logically bind a UICC to a specific M2M Node. If service n°6 is "available", this file shall be present. There shall be only one TLV object within this EF.

Annex D.1.3.4


No

TS-0003-118

The M2M-Node-ID Value field shall contain the M2M-Node-ID encoded as specified in oneM2M TS-0004 [4].

Annex D.1.3.4


No

TS-0003-119

This EF contains the local CSE Identifier, CSE-ID, for the M2M field node associated to the subscription in EF1M2MSID. If present, this file is used by the M2M field node to pre-provision the CSE-ID. If service n°1 is "available", this file shall be present. There shall be only one TLV object within this EF.

Annex D.1.3.5


No

TS-0003-120

The CSE-ID Value field shall contain the local CSE-ID formatted as a URI.

Annex D.1.3.5


No

TS-0003-121

The URI shall be encoded to an octet string according to UTF-8 encoding rules as specified in IETF RFC 3629 [19]. The tag value of the URI TLV data object shall be '80'.

Annex D.1.3.5


No

TS-0003-122

This EF contains the list of M2M Application Identifiers (AE-IDs) for the local M2M applications supported by the subscription in EF1M2MSID. If service n°4 is "available", this file shall be present.

Annex D.1.3.6


No

TS-0003-123

The Value field shall contain the M2M AE-ID formatted as a URI.

Annex D.1.3.6


No

TS-0003-124

The URI shall be encoded to an octet string according to UTF-8 encoding rules as specified in IETF RFC 3629 [19].

Annex D.1.3.6


No

TS-0003-125

This EF contains a list of pre-provisioned IN-CSE-ID used to determine the next point of contact after provisioning or M2M Service Bootstrapping. If service n°2 is "available", this file shall be present.

Annex D.1.3.7


No

TS-0003-126

The Value field shall contain the IN-CSE-ID formatted as a URI.

Annex D.1.3.7


No

TS-0003-

The URI shall be encoded to an octet string according to UTF-8 encoding rules as specified in IETF RFC 3629 [19].

Annex D.1.3.7

This refers to operation of the UICC. In testing if the IUT is equipped with an No

86

127 UICC the testing of the UICC is not part of M2M

TS-0003-128

This EF is used to pre-provision the FQDN of the MAF to be used for M2M Service Connection after M2M Service Bootstrapping. If service n°3 is "available", this file shall be present. There shall be only one TLV object within this EF.

Annex D.1.3.8


No

TS-0003-129

The MAF-FQDN shall be encoded to an octet string according to UTF-8 encoding rules as specified in IETF RFC 3629 [19]. The tag value of the MAF FQDN TLV data object shall be '80'.

Annex D.1.3.8


No

TS-0003-130

This EF contains one or more M2M Enrolment Function addresses. The first record in the EF shall be considered to be of the highest priority. The last record in the EF shall be considered to be the lowest priority. If service n°5 is "available", this file shall be present.

Annex D.1.3.9


No

TS-0003-131

This field shall be set to the type of the MEF address according to the following:

Value Name 0x00 FQDN 0x01 IPv4 0x02 IPv6

All other values are reserved

Annex D.1.3.9


No

TS-0003-132

This field shall be set to the address of the M2M Enrolment Function. When the MEF type is set to 0x00, the corresponding MEF Address shall be encoded to an octet string according to UTF-8 encoding rules as specified in IETF RFC 3629 [19].

Annex D.1.3.9


No

TS-0003-133

Unused bytes shall be set to 'FF'.

Annex D.1.3.9


No

TS-0003-134

Files at the UICC MF level are application independent as specified in ETSI TS 102 221 [24]. Only the EFDIR and EFICCID files are mandatory on UICC for the purpose of 1M2MSM applications. In any case all files shall be as specified in ETSI TS 102 221 [24].

Annex D.2.1.1


No

TS-0003-135

The EFs in the 1M2MSM ADF contain oneM2M subscription related information that is required for M2M field nodes operating in an oneM2M environment. This ADF shall be selected using its AID and information in EFDIR. The AID for 1M2MSM applications shall be constructed as specified in ETSI TS 101 220 [27].

Annex D.2.1.2


No

TS-0003-136

The DF1M2M substructure used to isolate the provisioning of network access dependent M2M service related information in a Network Access Application ADF is not needed for access network independent provisioning of an M2M service subscription in a 1M2MSM ADF. Therefore, all the EFs specified in clause D.1.3 shall be present at the 1M2MSM ADF level. The file structure of the ADF1M2MSM is illustrated in figure D.2.

Annex D.2.1.2


No

TS-0003-137

This clause specifies the procedures that shall be executed by M2M field nodes to interact with a oneM2M Service Subscription on UICC. They are applicable independently of the file structure supporting the oneM2M Service Subscription (1M2MSM ADF or DF1M2M under a Network Access Application ADF),

Annex D.2.2

This refers to operation of the UICC. In testing if the IUT is equipped with an UICC the testing of the UICC is not part

No

87

unless otherwise indicated.

of M2M

TS-0003-138

If the M2M field node wants to engage in M2M operation, then after UICC activation (see ETSI TS 102 221 [24]), the M2M field node shall select a 1M2MSM application, if a 1M2MSM application is listed in the EFDIR file, using the SELECT by DF name as defined in ETSI TS 102 221 [24].

Annex D.2.2.1


No

TS-0003-139

After a successful oneM2M application selection, the selected oneM2M AID is stored on the UICC. This application is referred to as the last selected 1M2MSM application. The last selected 1M2MSM application shall be available on the UICC after a deactivation followed by an activation of the UICC.

Annex D.2.2.1


No

TS-0003-140

If a oneM2M application is selected using partial DF name, the partial DF name supplied in the command shall uniquely identify a 1M2MSM application. Furthermore if a 1M2M application is selected using a partial DF name as specified in ETSI TS 102 221 [24] indicating in the SELECT command the last occurrence, the UICC shall select the oneM2M application stored as the last oneM2M application. If, in the SELECT command, the options first, next/previous are indicated, they have no meaning if an application has not been previously selected in the same session and shall return an appropriate error code.

Annex D.2.2.1


No

TS-0003-141

The M2M field node shall indicate to the oneM2M UICC application that the termination procedure is starting, by sending a particular STATUS command.

Annex D.2.2.2


No

TS-0003-142

To actually terminate the session, the M2M field node shall then use one of the mechanisms described in ETSI TS 102 221 [24].

Annex D.2.2.2


No

TS-0003-143

The M2M field node shall perform the reading procedure with EF1M2MST. If no oneM2M related service is indicated as available, the M2M field node shall assume that only the provisioning of mandatory parameters is available in this ADF.

Annex D.2.2.3


No

TS-0003-144

The M2M field node shall perform the reading procedure with EF1M2MSID and EF1M2MSPID, and EFCSEID, EFM2MNID, EFINCSEID, EFMAFFQDN according to available services indicated in EF1M2MST.

Annex D.2.2.4


No

TS-0003-145

Condition: Service number 4 shall be available in the oneM2M Service Table.

Annex D.2.2.5


No

TS-0003-146

Under this condition, the M2M field node shall perform the reading procedure with EFM2MAEID.

Annex D.2.2.5


No

TS-0003-147

Condition: Service number 5 shall be available in the oneM2M Service Table.

Annex D.2.2.6


No

TS-0003-148

Under this condition, the M2M field node shall perform the reading procedure with EFMEFID, if the related service is available.

Annex D.2.2.6


No

88

TS-0003-149

After identifying the supported authentication framework, the M2M field node shall check availability of Service number 7 in EF1M2MST: If the service is available, the D/G M2M Node shall perform GBA-related procedures with AUTHENTICATE - GBA security context (Bootstrapping Mode and Derivation Mode) with the parameters for GBA secure provisioning.

Annex D.2.2.6


No

TS-0003-150

After identifying the supported authentication framework, the M2M field node shall check availability of Service number 12 in EF1M2MST: If the service is available, the M2M field node shall perform a GBA-related procedures with AUTHENTICATE - GBA security context (Bootstrapping Mode and Derivation Mode) with the parameters for GBA Security Association.

Annex D.2.2.7


No

TS-0003-151

When a request (resource access) is evaluated by a Hosting CSE and an accessControlLocationRegions parameter is defined in the privileges attribute of the <accessControlPolicy> resources, the Hosting CSE checks whether the location of the Originator of a request is in the specific regions or not. Therefore, the Hosting CSE retains the location of the Originator otherwise the Hosting CSE shall acquire the location or deny the access. This annex describes how to describe the location regions and obtain the location of the Originator.

Annex F This is an overview clause (note that as a hanging paragraph the reference is inexact)

No

TS-0003-152

The practical way of describing the region or area is the circular presentation and generally the circle is characterized by the co-ordinates of a center point of the circle and a radius. Geographically, the center point and radius is described as longitude and latitude, and meter respectively. For this description, the accessControlLocationRegions parameter shall be represented as a circle.

Annex F.1.1

This proposes a representation and interpretation of stored data. No

TS-0003-153

As mentioned above, when accessControlLocationRegions parameter is defined, the Hosting CSE shall check the location of the Originator for access control. This clause describes how the Hosting CSE checks or obtains the location. The procedures shall be varies based on the region description, circle and country.

Annex F.2

This forms part of the access control rules where a geo-rule is enforced (note that as a hanging paragraph the reference is inexact)

Yes.

TS-0003-154

If the circular description is used as the location context constraints, the Hosting CSE shall check whether it has the current location of Originator or not. If not, it shall obtain the location of Originator. TS-0001 [1] defines a resource type for acquisition of location of a Target Node, <locationPolicy>. In order to , therefore, obtain the location of Originator, the Hosting CSE shall create <locationPolicy> and set the relevant attributes as follows:

• locationSource: Reliability of the location information is crucial so the location shall be obtained from trusted network. If the location is obtained by the other sources, the location information can be easily masqueraded. (i.e. GPS spoofing). Therefore, the locationSource attribute shall be set to ‘network-based'.

• locationTargetID: The Target Node shall be the Originator that needs to authorize the sent requests. The locationTargetID attribute shall be set to identifier of the Originator.

Annex F.2.1

Test of creation of policy. To be tested by inspection of the PiP Yes

TS-0003-155

Note that the other attributes are determined by local policies of Hosting CSE as described in clause 9.6.9 of oneM2M TS-0001 [1] and in order to obtain the location from the network, the Hosting CSE shall transform the oneM2M specified location request into network specified request.

Annex F.2.1

This is a note which should be informative but contains a requirement. No

TS-0003-156

2. The Hosing CSE shall evaluate the received request against the linked <accessControlPolicy> resource. If one of rule tuples that is about the request originator contains the accessControlLocationRegions parameter (circular description) and the Hosting CSE does not store the location of the Originator, the Hosting CSE shall do either continue the next step or deny the access. If the Hosting CSE has the location of the Originator, it is used for applying access control policy.

Annex F.2.1

Embedded within overall structure as a demonstration. It is not clear if this is a mandatory sequence as it is introduced by the following text "demonstrates how to acquire the location of the Originator when the accessControlLocationRegions parameter is defined".

Not at this time

89

TS-0003-157

NOTE 2: The Hosting CSE shall deny the access due to the fact that the Originator is not subscriber of the network or any other reasons (e.g. connection lost, server malfunction).

Annex F.2.1

This is a note which should be informative but contains a requirement. Whilst testable this should be transformed from the note format and integrated into the primary text

Not at this time

TS-0003-158

4. The Hosting CSE subscribes to a new area location notification service toward Location Server in the Network. The area information shall be based on the area defined by the accessControlLocationRegions parameters. If the multiple regions are defined, the multiple subscriptions shall be set.

Annex F.2.1


Not at this time

TS-0003-159

8. When the Originator crossed in(enter) or out(leave) the area, the Location Server shall notify of the Hosting CSE the location change. Thus, the Hosting CSE can keep track of the location's Originator and easily evaluate the access against location context constraint.

Annex F.2.1


Not at this time

TS-0003-160

Generally, the Originator's country-scale location can be determined by the Originator's IP address. If the Hosting CSE can distinguish the country using the Originator's IP address and it is also matched with the defined acccessControlLocationRegions parameter, the Hosting CSE shall grant the request subject to the acceptance of the other access control policies. Note that how to transform the IP address into country is out of scope.

Annex F.2.2 Part of the access control policy. Yes

TS-0003-161

However, if Hosting CSE cannot distinguish the country using the Originator's IP address, The Hosting CSE shall obtain the location coordinate (i.e., longitude and latitude) of the Originator from network and the Hosting CSE can distinguish the country using the location if available. The way of obtaining the location coordinate is defined in annex F of oneM2M TS-0004 [4]. Note that how to transform the location into country is out of scope.

Annex F.2.2 Part of the access control policy Yes

armour experiments and requirements€¦ · iot [7], gsma [13]). based on the analysis of the...

Documents