Deliverable D2.1 Generic test patterns and test models for ... · oneM2M structure and the oneM2M...

Deliverable D2.1

Generic test patterns and test models for IoT security testing

Version Version 1.0

Lead Partner Smartesting

Date 25/05/2016

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

Ref. Ares(2016)2472574 - 27/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 D2.1 “Generic test patterns and test models for IoT security testing” paves the way towards a security testing framework based on generic test patterns, which will mature during the first year. The test patterns are based on the analysis of the typical vulnerabilities identified for each experiment in D1.1, and are common across the ARMOUR experiments; hence the implementation of the test patterns into test cases could be manual or automated and it is experiment-specific, which will be further identified in the next tasks in Work Package 2.

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 19/04/2016 Deliverable plan and general security test patterns EGM, SMA

0.2 04/05/2016 Specific test patterns for Experience 1 and integration into the main document

ODINS, SMA

0.3 10/05/2016 INRIA contribution and its integration into the main document INRIA, SMA

0.4 13/05/2016 UI, SYN contribution and its integration into the main document UI, SYN, SMA

0.5 19/05/2016 JRC contribution to Section 3.2 JRC, SMA

0.7 20/05/2016 ODINS, UI, SYN, INRIA contributions to Section 5 and their integration

ODINS, Ul, SYN, INRIA, SMA

0.8 21/05/2016 Contributions of INRIA and their integration INRIA, SMA

0.9 24/05/2016 Proof reading and minor corrections UI, EGM, SMA

1.0 25/05/2016 Proof reading and minor corrections UPMC, JRC, ODINS, SYN, UI, SMA

4

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

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

2.1 Purpose and test patterns background .................................................................. 8

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

3 Security test patterns in the ARMOUR Framework ..................................................... 10

3.1 Security Test Patterns .......................................................................................... 10

3.2 Certification and labelling through test patterns ................................................... 12

4 Generic test pattern library .......................................................................................... 14

5 From Vulnerabilities to Specific Test Patterns for the IoT Segments .......................... 23

5.1 EXP I - Bootstrapping and groups sharing procedures ........................................ 23

5.1.1 Discussion ..................................................................................................... 23

5.1.2 Customization of test patterns ...................................................................... 23

5.2 EXP II - Sensor node code hashing ..................................................................... 25

5.2.1 Discussion ..................................................................................................... 25


5.3 EXP III - Secured bootstrapping/join for the IoT .................................................. 28

5.3.1 Discussion ..................................................................................................... 28


5.4 EXP IV - Secured OS / Over the air updates ....................................................... 29

5.4.1 Discussion ..................................................................................................... 29


5.5 EXP V - Trust aware wireless sensors networks routing ..................................... 29

5.5.1 Discussion ..................................................................................................... 29


5.6 EXP VI - Secure IoT service discovery ................................................................ 30

5.6.1 Discussion ..................................................................................................... 30

5


5.7 EXP VII - Secure IoT platform .............................................................................. 32

5.7.1 Discussion ..................................................................................................... 32


5.8 Summary .............................................................................................................. 33

6 Initial formalisation of test patterns based on models ................................................. 34

7 Conclusion .................................................................................................................. 37

8 References .................................................................................................................. 38

9 Annex 1 : Mapping of security test patterns to vulnerabilities ..................................... 39

6

1 Executive summary

The intention of this deliverable is to describe the work done in Task 2.1, which consists in defining guidelines for security testing and test patterns to formalize the intentions of given security requirements results from deliverable D1.1 [1]. The notion of test pattern is widely known and it’s an effective and an efficient possibility to capitalize the knowledge on testing solutions addressing vulnerabilities testing [6]. A security test pattern is defined as a solution to describe the testing procedure for each class of vulnerability. The deliverable D1.1 identified 18 vulnerability patterns, based on which D2.1 proposes 14 generalized security test patterns to ensure the IoT segments resistance to these threats. On the one hand, the generalized test patterns were defined based on the vulnerabilities. On the other hand, they were defined based on the analysis of the four IoT segments (connectivity, devices and data, application and services, platforms) and based on the seven ARMOUR experiments. To describe the generic patterns, we used an existing security template as defined in [2,6] applied in an IoT context. The pattern is distinguished by an identifier and a pattern name and further described through six fields, shortly defined as follows:

• Context: defines the specific context in which the security test pattern applies and identifying the security approach(es) in which the pattern may be applied.

• Problem/Goal: defines the testing problem the pattern addresses. • Solution: description of the test procedure. • Discussion: shortly discusses the pattern, for instance the pitfalls of applying the

pattern, the potential impact it has on test design in general etc. • Related patterns: any other test pattern that can be related. • References: some other bibliographic references to the pattern or external

associated elements, for instance the vulnerabilities it covers. The test pattern specificities for each experiment are explained in this deliverable through a test pattern customization, which resulted in 42 customizations. The initial template was not sufficient to capture the customization of the security test pattern for each experiment. Thus, we augmented this template in order to describe all relevant information about the customization:

• Stage: defines the specific stage of the IoT tested object. • Entities: identifies the entities involved by the test pattern. • Customization: details for each case how the solution is customized and if

necessary further specificities on the test procedure.

We have then provided a proof-of-concept on formalizing the test patterns into test purposes based on the work in the seventh experiment, which might be further used in the other experiments based on the identified experiment needs. Hence, this work in M4 (month four – May 2016) is in its initial state and a new incremented version will be made available in M12 (January 2017). This new version will integrate more details on the test models and the test pattern’s formalization, as well as if necessary an extension of the security test patterns.

7

Based on the work done in D2.1, further test strategies will be investigated in T2.2 toward the conception of test suites for security compliance testing of IoT systems. The document is organized as follows: Section 2 introduces the security test patterns and test pattern’s in general background and the methodology used to define the generalized security test patterns. Section 3 positions the security test patterns in the ARMOUR framework. Section 4 defines the initial security test patterns catalogue. Section 5 describes the customization of the test patterns for each experiment. Section 6 illustrates the initial formalization of test patterns though a proof of concept on experiment 7, before concluding in Section 7. The mapping between the vulnerabilities, defined in D1.1, and the security test patterns, in D2.1, is given in Annex 1.

8

2 Introduction

Work package 2 (WP2) during its Phase 1 works on the creation of a large-scale Security & trust testing framework based on security test patterns and models. The task T2.1 proposes dedicated and generic security test patterns based on a vulnerability analysis. These test patterns pave the way towards the design of test suites for labelling and certifying M2M devices, one of the objectives of the ARMOUR project.

2.1 Purpose and test patterns background Security testing has recently received much attention in the research and especially in industry areas. Its aim is to increase the user’s confidence in the system by ensuring its conformance to security requirements. In the literature, two main goals for security testing are considered:

• Functional security testing, which ensures that the security properties and functions are implemented correctly

• Vulnerability testing, which aims to identify and discover the potential vulnerabilities based on risk and threat analysis.

Systematic and efficient documentation of security requirements, issued either from security functions or vulnerability analysis, is a must for such certification and labelling schemes. Test patterns are a well-known approach for defining test procedures and facilitating the reuse of known solutions to recurring problems in various domains, which have gained recently popularity in security testing [6]. For instance, test patterns have been also used as means for defining an initial library for security testing of web applications by the DIAMONDS project [2] and then within the RASEN project [3]. The DIAMONDS project, provided an initial set of 15 security test patterns focused on dynamic testing enriched with security functional requirements (SFR) from the Common Criteria [9]. In addition, the RASEN project [4] goes further by relying on the TOP 10 web weaknesses from the Open Web Application Security Project (OWASP) and the Common Attack Pattern Enumeration and Classification (CAPEC) from the MITRE corporation [11]. In addition, the oneM2M initiative provides a library of functional test patterns, written in a structured natural language – TPLan [5], which may be later used for certification purposes. Hence, the structured template for their test patterns is very specific to the oneM2M structure and the oneM2M initiative needs. oneM2M intends to get all its requirements to be covered by the test patterns, including security one. ARMOUR intends to contribute to the development of security tests for oneM2M but also to provide as much as possible generic security test patterns applicable to various IoT standards. The methodology developed in the first release of this D2.1 deliverable thus focuses on delivery of generic test patterns whereas its second release, due M12, may also include TPLan based test patterns for oneM2M.

9

2.2 Methodology ARMOUR task T1.1 has proposed a security framework based on risk and threat analysis that defines a list of potential vulnerabilities for all four IoT segments: (i) devices and data, (ii) connectivity, (iii) applications and services and (iv) platforms. In order to define the test patterns for each vulnerability, each partner has conceived test procedures for verifying its system resistance to the vulnerabilities of its experiments. Based on these test procedures specific for the ARMOUR experiments, we have created a library of test patterns generalized to the four IoT segments: data and devices, networks, applications and services and platforms. Figure 1 illustrates the methodology applied for the definition of generalized security test patterns, as input in T2.2 and towards the conception of security test cases.

Figure 1 - Security Test Patterns definition methodology

10

3 Security test patterns in the ARMOUR Framework

This section defines the security test patterns used in the ARMOUR Frameworks, as well as the elements specific for each IoT Segment. Test patterns build on top of the vulnerability patterns:

• Vulnerability patterns, as identified within D1.1, intend to identify from a risk analysis, the threats to which the system is vulnerable.

• Security test patterns, as being developed in the previous section, describe the test procedure (test steps) to be undertaken to evaluate the existence of absence of vulnerability.

In addition, this section positions the security test patterns with respect to the classical certification and labelling process (for more details refer to project activities pursued within Work Package 4).

3.1 Security Test Patterns The security test patterns proposed by [2] are adapted to the needs of the ARMOUR project. We initially used their template to take into account the types of information expected to be provided for each pattern. Authors in [6] define on very high level the pattern as the “solution to a problem that arises within a specific context”. Important in the definition of a test pattern is the context of the text patterns, which is described by the typology of the test pattern and the chosen approach for security deployment:

• Test patterns typology: several types of test patterns have been identified with respect to the security capabilities of the software that are part of the pattern context [6, 10].

o Generic: the test pattern is generic and might be applied in different contexts.

o Organisational: the test pattern relates to the organisational factors for instance tangible factors such as available resources (human or financial).

o Architectural: the test pattern relates to the system’s architecture in terms of interaction between components.

o Design: relates to the process of defining software (security) functions, objects etc. of the system in order to satisfy the user’s requirements.

o Behavioural: relates to the behaviour of the system. o Test data: relates to the data being exchanged between the various entities

and the SUT.

• Security approach: The concept of security approach is used here as presented

by Schumacher et al. in their book on security patterns [6]. According to them, security approaches define groups of related ways to address potential security violations. They identify the following group of security approaches:

o Planning embodies the organization-wide standard operation procedures (documentation) for prevention, detection, and response.

o Prevention consists in efforts aiming at actively impeding unwanted incidents, i.e. undesirable activities that would compromise security assets.

o Detection aims at identifying or detecting unwanted incidents on the element to be protected.

11

o Diligence refers to ongoing proactive measures for updating security plans to improve the overall security posture of an organization.

o Response approaches are those addressing unwanted incidents or other security violations, after they have been detected.

Security approaches are not usually applied alone, but in various combinations, given the natural dependencies between each of the aspects they cover [6]. Therefore, the context for a security test pattern may involve a combination of several security approaches. We give the test pattern template and its description below.

Test Pattern ID Unique ID of the security test pattern.

Test Pattern name A meaningful name for the test pattern.

Context To which specific context does it apply? This includes the kind of test pattern (organisational vs. design, generic, architectural, behavioural or test data, etc.) as well as the security approach(es) in which the pattern may be applied.

Problem/Goal What is the testing problem this pattern addresses and which are the forces that come into play for that problem? In certain cases, a pattern may not solve a specific problem, but provides a mean for achieving a particular goal with regard to security testing. In those cases, the goal(s) to be achieved by the pattern should be provided instead.

Solution A full description of the test procedure, potentially including examples of applications.

Discussion (optional)

A short discussion on the pitfalls of applying the pattern and the potential impact it has on test design in general and on other patterns applicable to that same context in particular.

Related patterns (optional)

Test design pattern related to this one or system design patterns in which faults addressed by this test pattern might occur. This section is optional if no related pattern can be named.

References (optional)

Bibliographic references to the pattern or external associated elements. This section is also optional and will be omitted, if no reference can be provided.

Table 1 - Security test pattern

In addition, each security pattern can be instantiated differently with respect to the IoT segments and its context. For this reason, we extend the classical test pattern structure for the specificities of the IoT segments. These specificities were identified as follows:

12

Test Pattern ID Reference to the general pattern

Stage Define the specific stage of the IoT tested object. For instance: • Bootstrapping • Group sharing • Software update distribution • OS / Over the air updates • Entities Authentication • New software announcement and authentication • Normal network operation • Message request (for ex request sent to a platform for update,

creation, deletion, notification etc)

Entities Network, Devices (sensors, actuators), Gateways (integration of several device), and any component of the infrastructure (AAA server, Attribute Authority, Capability Manager, PDP and Pub/Sub server), service provision platform.

Customization Details for each case how the solution is customized and if necessary specificities on the test procedure.

Table 2 - Customization of a test pattern for IoT segments

3.2 Certification and labelling through test patterns The ARMOUR deliverable D1.1 identifies the needs of reference framework for certification and labelling. As mentioned, in Europe, to evaluate computer security within products and systems it exists a structure named ITSEC (Information Technology Security Evaluation Criteria) which has evolved towards Common Criteria which is also known as ISO 15408 [9]. In more details, Common Criteria defines different levels of evaluation called Evaluation Assurance Levels (EAL) from 1 to 7. In comparison to the initial certification approach defined by the Orange book, which was focused on protecting classified information, the Common Criteria is wider and permits systems and devices to be evaluated against a specific protection profile. The protection profile is based on Security Targets, which are the documents, which identify the security properties of the target of evaluation. In addition, security objectives, security enforcing functions and security mechanisms. The combination of the vulnerability patterns (ARMOUR D1.1. [1]) with the security test patterns, provided in this deliverable, easily integrate these features and create a logical link between the test patterns and the protection profile. In other words, the security objectives and the properties (e.g., confidentiality, integrity and authentication) in the protection profile can be mapped to the vulnerabilities and security test patterns to be implemented. Finally, the security mechanisms are the security test patterns that enable these vulnerabilities on the system under test.

13

Thus, the goals of the security test patterns are twofold: (i) define the procedures for activating these vulnerabilities on the system and (ii) act as a preventive measure (i.e. if such procedures succeed, then the system is not secured) to the vulnerabilities they cover. The creation of these logical links makes the certification and labelling process more systematic. The Figure 2 below illustrates the integration of the test patterns in the certification process.

Figure 2 - Certification and Labelling through test patterns

Then, at the end of the process the certified product receives a certification proof and the related label, which is associated to the initial test pattern. As it will be described in the subsequent deliverables of ARMOUR, the label is only valid for a specific domain and/or testing environment.

14

4 Generic test pattern library

From the template proposed in the previous subsection, the different patterns of the test library, which will be used as basis for the experiments, are established. Thus, the aspects listed on the pattern template for such patterns are detailed.

Test Pattern Id TP_ID1 Test Pattern name Resistance to an unauthorized access, modification or deletion of

keys. Context Kind of test pattern: design

Security approach(es): prevention

Problem/Goal The pattern addresses how to check that a key cannot be obtained, replaced or deleted from an entity in an unauthorized way.

Solution Test procedure template 1. Consider a key derived from a master key into the entity under

test 2. An attacker gains access and knows the master key and the

derived key 3. The attacker:

a. Can discover (by iterating on different available algorithms) how the key was derived of the master key, being aware that the first is available only a limited time. Thus, the attacker can access the secure channel. Besides, it can construct any operation that performs as the impersonated entity

b. Can delete the derived key from the entity. Thus, the attacked entity cannot perform any security-related operation

Discussion The access, modification or deletion of keys must require authentication and authorization mechanisms. A successful execution of this test means that the system is vulnerable to this threat.

Related patterns TP_ID8

References Vulnerabilities • Discovery, deletion or replacement of keys stored in sensors,

gateways or M2M infrastructure (V1, V2, V3, V4, V5). Countermeasures • Strong authentication to access to keys.

Test Pattern ID TP_ID2

Test Pattern name Resistance to the discovery of sensitive data.

15

Context Kind of test pattern: test data Security approach(es): prevention

Problem/Goal The pattern addresses how to check that a sensitive data, such as key, cannot be obtained from an entity by using sensitive functions outside the HSM (Hardware Security Module).

Solution Test procedure template 1. Identify all sensitive functions that may reveal sensitive data,

such as service-layer keys from the system under test. 2. For each of the identified function create a call to be

interpreted correctly by the system under test (SUT). 3. The attacker obtains the sensitive data from the SUT using the

sensitive functions. Discussion The sensitive functions must be performed within the HSM to

ensure they do not reveal information like service-layer keys.

Related patterns TP_ID1, TP_ID9

References Vulnerabilities • Discovery of sensitive data in sensors or gateways (V6).

Countermeasures • Secure execution of sensitive functions in sensors or

gateways.


Test Pattern name Resistance to software messaging eavesdropping.

Context Kind of test pattern: design Security approach(es): prevention

Problem/Goal The pattern addresses how to check that a third-party entity cannot read the content of software updates exchange between an entity and the software provisioning entity whether the communication is well encrypted.

Solution Test procedure template 1. An entity sends a software update request to software

provisioning entity. 2. The authority entity sends the requested software update to

the entity. 3. An attacker observes and intercepts both messages and can

read their content. Discussion Communications between entities and the software provisioning

entity must use secure protocols with modern cryptographic algorithms to encrypt such communications.

16


References Vulnerabilities • General Eavesdropping on M2M Service-Layer Messaging

between Entities (V7).

Countermeasures • Secure communication using session keys (keys with

limited lifetime set by a security policy for instance), which can be also derived from M2M service-layer keys.

• Secure communication between M2M entities providing end-to-end confidentiality.

Test Pattern ID TP_ID4 Test Pattern name Resistance to alteration of requests. Context Kind of test pattern: design

Security approach(es): detection and response

Problem/Goal The pattern addresses how to check that a third-entity cannot modify a request about a private element of another entity.

Solution Test procedure template 1. An entity sends a request about a private element, like a token

or a key, to authority entity. 2. An attacker intercepts the request and replaces the information

used to generate the private element. 3. The attacker forwards the request to authority entity. 4. The authority entity sends the private element (with wrong

information) to the entity. Discussion Communication between an entity and the authority entity to

request a private element must use secure communication protocols that provide mutual authentication, integrity and confidentiality. The successful execution of such test means that the object under test is not secure.

References Vulnerabilities • Alteration of messaging between devices (V8). Countermeasures • Use of security associations, mutual authentication and

confidentiality. • Proven resistance to man in the middle attacks. • Limited life session keys.

Test Pattern ID TP_ID5 Test Pattern name Resistance to replay of requests.

17

Context Kind of test pattern: design and test data Security approach(es): detection and response

Problem/Goal The pattern addresses how to check that a third-entity cannot obtain a private element of another entity by replay of requests.

Solution Test procedure template 1. An entity sends a request about a private element, like a token

or a key, to authority entity. 2. An attacker intercepts the request. 3. The authority sends the private element to the entity. 4. The attacker replays the request of the private element to

authority entity. 5. The authority entity sends the private element to the attacker. 6. The attacker knows the private element of the entity.

Discussion Communication between an entity and the authority entity to request a private element must use secure communication protocols that include functionality to detect replay attacks. The successful execution of such tests means that the object under test is not secure.

References Vulnerabilities • Replay of messaging between devices Countermeasures (V9). Countermeasures • Replay protection. • Keys can be derived from M2M keys. • Secure communication link.

Test Pattern ID TP_ID6 Test Pattern name Run unauthorized software

Context Kind of test pattern: design and test data Security approach(es): detection and prevention

Problem/Goal The pattern addresses how to check that an entity should not run an unauthorized software if it does not pass a prior integrity verification process.

Solution Test procedure template 1. Consider that an entity has downloaded unauthorized software

from a particular URL using a determined command. 2. The entity runs the downloaded unauthorized software. 3. The software may reveal sensitive data, such as cryptographic

material of the entity. Discussion The entity must perform an integrity verification test to the

software in order to ensure that it comes from a reliable source.

18

References Vulnerabilities • Unauthorized or corrupted applications or software in sensors

or gateways (V10). Countermeasures • Integrity verification. • Policy-based actions.

Test Pattern ID TP_ID7 Test Pattern name Identifying security needs depending on the M2M operational

context awareness. Context Kind of test pattern: design


Problem/Goal Depending on the specific needs of the use cases that can be accommodated in a wireless sensor network, different levels of security must be possible to be applied. In other words, following a static security level may lead to inefficient usage of resources.

Solution Test procedure template 1. Create a list of the use cases (or operational contexts). 2. Create a list of attacks mitigated by the proposed solution,

e.g. replay attack, modification attack, black-hole attack, grey-hole attack.

3. Create an inventory including the security metrics and parameters to be included per use case (or operational context) and categorize them as mandatory or optional.

4. Apply the proper combination of metrics related to the use cases and demonstrate that security attacks are properly mitigated.

5. Repeat test with different combination of metrics in order to demonstrate the difference in the sensitivity of identifying attacks.

Discussion The solution demonstrated in this experiment is adjustable by the user in order to fulfil specific (or adverse) needs of several use cases. One of the main advantages is the ability to adjust the sensitivity of the solution in terms of attack mitigation.

Related patterns

TP_ID4, TP_ID5

References Vulnerabilities • M2M security context awareness (V12). Countermeasures • Context Inventory and Assessment on Sensitivity.

Test Pattern ID TP_ID8 Test Pattern name Resistance to eaves dropping and man in the middle.

19

Context Kind of test pattern: design Security approach(es): prevention

Problem/Goal The pattern addresses how to check that a third-party entity cannot read the content of messages exchange between an entity and the authority entity whether the communication is well encrypted.

Solution Test procedure template 1. An entity sends a private element (token or key) request to the

authority entity. 2. The authority entity sends the private element to the entity. 3. An attacker observes and intercepts both messages and it can

read their content. Discussion Communications between entities and the authority entity must

use secure protocols with modern cryptographic algorithms to encrypt such communications.

Related patterns

TP_ID1, TP_ID11

References Vulnerabilities • Eaves dropping and man in the middle attack (V13). Countermeasures • Secure communication link.

Test Pattern ID TP_ID9 Test Pattern name Resistance to transfer of keys via of the security element. Context Kind of test pattern: design


Problem/Goal The pattern addresses how to check that a key cannot be obtained from an entity via of its Hardware Security Module (HSM).

Solution Test procedure template 1. An attacker accesses to the HSM of an entity. 2. The attacker gets the key of the entity. 3. The attacker can construct an operation that performs as

the impersonated entity Discussion Any communication with the HSM must be done using libraries

provided by the latter, which guarantee the security of such communication.


References Vulnerabilities • Transfer of keys via independent security element (V14). Countermeasures • Physical and logical binding of HSM to sensors or gateways.

20

Test Pattern ID TP_ID10 Test Pattern name Resistance to Injection Attacks Context Kind of test pattern: test data


Problem/Goal Injection attacks, is a frequent security threat scenario for IoT structures. It consists in an attacker being able to control or disrupt the behaviour of the target using inputs with attacker adds elements that are interpreted by the system, which may cause unintended or potentially security threatening steps.

Solution Test procedure template 1. Identify all interfaces of the system under test used to get

inputs from the external world, including kind of data potentially exchanged through the interfaces.

2. For each of the identified interfaces create an input element that includes code snippets likely to be interpreted by the system under test (SUT).

3. Use each of the input elements created in step 2 as input to the SUT and for each of those check that the SUT does not give positive response.

Discussion Systems should use for instance prepared statements with parametrized queries, stored procedures, white list input validation. The SUT should provide a mechanism to observe and evaluate the events triggered by the interpretation of the added snippets.

References Vulnerabilities • Injection (V16). Countermeasures

• Keeping un-trusted data separate. • Use of parametrized APIs or avoid special characters

usage.

Test Pattern ID TP_ID11 Test Pattern name Detection of flaws in the authentication and in the session

management. Context Kind of test pattern: design


Problem/Goal The pattern addresses how to check that an attacker cannot use flaws in the authentication process or in the session management to impersonate another entity.

Solution Test procedure template 1. An entity requests authorization to access a resource to the

authority entity. 2. The authority entity sends the authorization to the entity.

21

3. An attacker intercepts the authorization and it can access the resource.

Discussion Communications between entities and the authority entity must use secure protocols which carry out encryption and/or strong session management security control.


References Vulnerabilities • Session management and broken authentication (V17). Countermeasures • Security control.

Test Pattern ID TP_ID12 Test Pattern name Detection of architectural security flaws. Context Kind of test pattern: architectural

Security approach(es): detection and response

Problem/Goal The pattern addresses how to check that the application architecture provides a good security between entities of the scenario.

Solution Test procedure template 1. An entity requests authorization to access a resource to the

authority entity. 2. Two possible sub-patterns

a. From the server side: the authority entity always authorizes any entity to access the resource.

b. From the client side: the entity obtains the authorization and gives it to another entity in order to access the resource.

Discussion Implement mechanisms to ensure the architectural security between the different entities.

Related patterns

TP_ID11

References Vulnerabilities • Security misconfiguration (V18). Countermeasures • Clean application architecture.

Test Pattern ID TP_ID13 Test Pattern name Detection of insecure encryption and storage of information. Context Kind of test pattern: design


Problem/Goal The pattern addresses how to check that an entity encrypts and stores in a secure way a specific information.

22

Solution Test procedure template 1. An encrypted message is received by an unauthorized entity. 2. The entity can decipher the message and read its content.

Discussion The information should be properly encrypted and stored so that only the group of authorized entities is able to decipher it.

References Vulnerabilities • Insecure cryptographic storage (V19). Countermeasures • Standard algorithms.


Test Pattern name Resistance to invalid input data Context Kind of test pattern: design


Problem/Goal The pattern addresses how to check if an M2M entity is resistant to invalid inputs that try to grant an attacker access to unintended functionality or privilege escalation. This is specifically in relation with the level of access control to privileged functions.

Solution Test procedure template 1. Identify all interfaces of the system under test used to get

inputs from the external world meant to access to functionality or change privileges.

2. For each of the identified interfaces create an input element that includes invalid data in order to access to unintended functionality or privilege escalation.

3. Use each of the input elements created in step 2 as input to the system under test and for each of those check that the SUT does not give unauthorized access.

Discussion Systems should handle the role management with the help of access control policies. The SUT should provide a mechanism to observe and evaluate the events triggered by the interpretation of the added snippets.

Related patterns

TP_ID10

References Vulnerabilities • Invalid Input Data (V20). Countermeasures • Implement at least privileges.

23

5 From Vulnerabilities to Specific Test Patterns for the IoT Segments

5.1 EXP I - Bootstrapping and groups sharing procedures 5.1.1 Discussion This section details how the test patterns, explained in the previous section, will be applied on the experiments defined in the first deliverable for the bootstrapping and group sharing stages. Because of this, in the next subsection will be indicated the selected patterns from the library, the stage where they are applied, the entities listed and a brief description about the customization of the test. 5.1.2 Customization of test patterns Test Pattern ID TP_ID1 Stage Bootstrapping and group sharing

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

Customization Private keys of the different entities (keys for secure communication or CP-ABE keys) will be stored in a keystore protected by an authentication mechanism. Thus, only they will have access to such sensitive data.


Stage Bootstrapping and group sharing Entities Sensors and gateways

Customization Any function that makes use of private keys of an entity (e.g. to sign data or to decrypt information) is made within a HSM. This ensures that such keys will not be revealed to the outside.

Test Pattern ID TD_ID4 Stage Bootstrapping and group sharing

Entities Sensors, gateways, Attribute Authority (group sharing stage) and Capability Manager (bootstrapping stage)

Customization

In the bootstrapping stage, the authority entity corresponds to the Capability Manager and the private element would be the capability token. Moreover, in the sharing group stage, the authority entity corresponds to the Attribute Authority and the private element would be the CP-ABE key. In both stages the information used to generate the private element (capability token or CP-ABE key) is the certificate of the entity. In addition, to prevent the attacker can modify this information and the generation of this element be erroneous, the communication will use protocols such as HTTPS or CoAP-DTLS (CoAPS).

24

Test Pattern ID TP_ID5 Stage Bootstrapping and group sharing

Entities Sensors, gateways, Attribute Authority (group sharing stage) and Capability Manager (bootstrapping stage)

Customization

In the bootstrapping stage, the authority entity corresponds to the Capability Manager and the private element would be the capability token. Moreover, in the sharing group stage, the authority entity corresponds to the Attribute Authority and the private element would be the CP-ABE key. To avoid the attacker can intercept and forward the request in order to obtain the private element (capability token or CP-ABE key) associated with an entity, the communication will use protocols such as HTTPS or CoAP-DTLS (CoAPS).

Test Pattern ID TP_ID6 Stage Bootstrapping and group sharing Entities Sensors and gateways

Customization

Both in the bootstrapping and group sharing stage, sensors and gateways have to download and install some security firmware. Such software must be signed by its manufacturer, as both entities will carry out a signature verification process. If this verification is not valid, the firmware will not be installed.

Test Pattern ID TP_ID8 Stage Bootstrapping and group sharing


Customization

In the bootstrapping stage, the authority entity corresponds to the Capability Manager and the private element would be the capability token. Moreover, in the sharing group stage, the authority entity corresponds to the Attribute Authority and the private element would be the CP-ABE key. To avoid the attacker can intercept and read the content of the exchanged messages, including the private element (capability token or key CP-ABE) associated with an entity, the communication will use protocols such as HTTPS or CoAP-DTLS (CoAPS).

Test Pattern ID TD_ID9 Stage Bootstrapping and group sharing


Customization

Communications between entities and the HSM will be performed using the functions defined in the libraries of such HSM. Because of that, no one cannot obtain private keys of these entities because they will find contained in this secure module.

25

Test Pattern ID TP_ID11 Stage Bootstrapping Entities Sensors, gateways and Pub/Sub server

Customization

During the bootstrapping, the authority entity corresponds to the Capability Manager and the authorization element would be the capability token. Moreover, the resource would be the action of "publish" in the Pub/Sub server. To prevent the attacker can intercept the capability token associated with an entity and publish information impersonating her, the communication will use protocols such as HTTPS or CoAP-DTLS (CoAPS).

Test Pattern ID TP_ID12 Stage Bootstrapping


Customization

During the bootstrapping, the authority entity corresponds to the Capability Manager and the authorization element would be the capability token. Moreover, the resource would be the action of "publish" in the Pub/Sub server. To avoid an entity can give a capability token associated with it to another entity and that it can publish information in an unauthorized way, such token will include the certificate of the entity that requested it. Thus, the certificate which will be used in secure communication against the Pub/Sub server to publish information must match with the one included in the capability token.

Test Pattern ID TP_ID13 Stage Group sharing Entities Gateways and Pub/Sub server

Customization

Some gateways, during the group sharing stage, are subscribed in the Pub/Sub server to receive updates about a certain topic (temperature, humidity, etc.). Such information will be encrypted using the CP-ABE cryptographic scheme under a certain policy of attributes, e.g. ((att1 || att2) && att3). Thus, only those gateways which set of attributes satisfies such encryption policy will be able to decrypt the information using their CP-ABE key and to read their content.

5.2 EXP II - Sensor node code hashing 5.2.1 Discussion In this section, some test patterns presented in the Test Pattern Library are customised in order to address the security vulnerabilities identified in Deliverable 1.1 - ARMOUR

26

Experiments and Requirements. The customisation of test patterns is performed in order to meet the conditions described for the code hashing experiment, allowing to test and validate different security algorithms and approaches in order to identify the most appropriate solution to provide a secure and energy efficient software update mechanism on resource-constrained devices without operating system. 5.2.2 Customization of test patterns Test Pattern ID TP_ID1 Stage Entities Authentication

Entities Devices and Software Provisioning Servers

Customization

Test only focused on discovery of master keys Attacker device discovered master keys (Hardware ID, Software Fingerprint) and tries to successfully reply to challenges from software provisioning servers, testing different encryption and hashing algorithms.


Stage Software update distribution


Customization Different encryption technologies will be tested to secure the communication channel for software updates.

Test Pattern ID TP_ID4 Stage Entities Authentication Entities Devices and Software Provisioning Servers

Customization

- Attacker intercepts message from device trying to access a software update - Attacker changes software version to a version for which the fingerprint was discovered - Attacker as successfully authenticates and as access to a valid encryption key To detected attack: Challenging messages are signed with the fingerprint of the software currently installed to be used to verify integrity.

Test Pattern ID TP_ID5 Stage Entities Authentication Entities Devices and Software Provisioning Servers

Customization

Attacker tries to replay messages from previous authentication challenges to try to successfully authenticate itself against other entities. To avoid success, challenges between devices and Software Provisioning Systems use hashing algorithms over random numbers to be used as challenges.

27

Test Pattern ID TP_ID6 Stage Authentication and software distribution Entities Devices and Software Provisioning Servers

Customization

The testing pattern aims at the detection of devices running corrupted software and at the prevention of corrupted software installation. Prevention: Software fingerprints are used alongside encrypted communication channels to ensure software authenticity, enabling devices to verify software before installation/execution Detection: Fingerprint of software installed on devices are used in the authentication of entities, where mismatches in the hashes due to use of different fingerprints will lead to the authentication failure.

Test Pattern ID TP_ID8 Stage New software announcement and authentication


Customization

Parts of messages can be read by attacker; however sensible information should not be read. Different security mechanisms will be tested in order to evaluate mechanisms that provide eavesdropping and man in the middle resistance without the setup of an encrypted communication channel

Test Pattern ID TD_ID9 Stage Entities Authentication Entities Devices

Customization

- Attacker device has access to hardware identifiers of legitimate device via hardware module transfer. - Attacker device uses transferred hardware identifiers to try to successfully authenticate against a legitimate software provisioning server. - Attacker authenticates with success or authentication fails. Authentication of devices should not be possible using only hardware keys. Other keys such as software fingerprints are also used to improve security of authentication process.

Test Pattern ID TD_ID13 Stage Software update distribution Entities Devices and Software Provisioning Servers

Customization Software artefact is encrypted and attacker is not able to read its content nor get the corresponding fingerprint

28

5.3 EXP III - Secured bootstrapping/join for the IoT 5.3.1 Discussion We illustrate which test patterns can be used for the scenario of Secured bootstrapping based on IETF 6TISCH Join Process. The main objective of the experiment is to test, prototype and provide secured communication to provide a secured join/bootstrap procedure. 5.3.2 Customization of test patterns

Test Pattern ID TD_ID4 Stage Secured Bootstrapping

Entities Joining Node (JN), Joining Assistant (JA), Join Coordination Entity (JCE)

Customization Communication between the JN and the JCE (through the JA) wlll use object security, such as COSE. This will include protection about packet alteration by a man in the middle.

Test Pattern ID TP_ID5 Stage Secured Bootstrapping

Entities Joining Device (JN), Join Assistant Device (JA) and/or other entities like JCE (Join Coordination Entity)

Customization We will use CBOR based object signing and encryption defined by IETF COSE

Test Pattern ID TD_ID8 Stage Secured Bootstrapping


Customization Since all communication between the JN and the JCE is protected though object security, as defined in IETF COSE, a man-in-the middle attacker should not be able to any information which can compromise the system.

Test Pattern ID TD_ID9 Stage Secured Bootstrapping Entities Joining Device (JN),JCE (Join Coordination Entity)

Test Pattern ID TP_ID1 Stage Secured Bootstrapping


Customization Shared Key between JN and JA. We will use CBOR based object signing and encryption defined by IETF COSE.

29

Customization The PSK (if PSK mode is used) will be installed in the JN and JCE through out-of-band communication. Both the JN and JCE hence must have an interface that allows installing the PSK.

5.4 EXP IV - Secured OS / Over the air updates 5.4.1 Discussion We illustrate which test pattern can be used for the scenario of 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. 5.4.2 Customization of test patterns Test Pattern ID TP_ID6 Stage Secured OS / Over the air updates Entities Devices

Customization

OTA over riot will implement: • separate update code from main current code • download binary with high level protocol (COAP) over

encrypted channel (e.g., 6TISCH). • signed images • roll-back mechanism if new image is not functional

5.5 EXP V - Trust aware wireless sensors networks routing 5.5.1 Discussion This section provides further specifications regarding the test patterns to be followed for the experiment of trust-aware wireless sensor network routing, based on the vulnerabilities identified and described in Deliverable 1.1. 5.5.2 Customization of test patterns Test Pattern ID TP_ID4 Stage Under normal network operation Entities Sensors and gateways

Customization

In this experiment, the focus will be on the applicability of the proper and effective security associations and mechanisms to tackle the alteration of data in the structure of packets exchanged between sensor devices and/or gateways. The identification that a node acts maliciously will be specially handled by the routing protocol to exclude the nodes from future interactions (e.g. packet forwarding).

Test Pattern ID TP_ID5 Stage Under normal network operation

30

Entities Sensors and gateways

Customization

Under normal operation, the nodes comprising the wireless sensor network must be able to identify and mitigate replay attacks. For this experiment, a replay attack is considered as resending messages or requests to the WSN gateway. In case of identifying a replay attack, the benevolent node excludes the malicious node, following the dynamic nature of trust-aware (extended RPL) routing protocol under study.

Test Pattern ID TP_ID6 Stage Bootstrapping and under normal network operation Entities Sensors and gateways

Customization

The purpose of this experiment is to mitigate the attack of running unauthorized software in a dynamic fashion, as described in the respective M2M document (policy-based actions). Taking advantage of the trust-aware routing protocol, the node running the malicious software will be revealed and be excluded from future routing transactions in the wireless sensor network.

Test Pattern ID TD_ID7 Stage Under normal network operation Entities Sensors and gateways

Customization

This experiment deals with the mitigation of attacks achieved by the routing protocol, as described above. By creating an inventory, the user may easily select and apply the proper routing metrics that would help on mitigating attacks according to his specific needs, prior to compiling the code to the sensor nodes. Moreover, it is highlighted that each routing metric used for routing purposes is related to a weighting factor that is related to the sensitivity of identifying and mitigating an attack, as described in more details in Deliverable 1.1.

Test Pattern TP_ID8 Stage Under normal network operation


Customization This experiment will demonstrate a more dynamic way for avoiding such attacks, by facilitating the trust-aware routing protocol implementation.

5.6 EXP VI - Secure IoT service discovery 5.6.1 Discussion This section provides further specifications regarding the test patterns to be followed for the experiment of secure service discovery, based on the vulnerabilities identified and described in Deliverable 1.1.

31

5.6.2 Customization of test patterns Test Pattern ID TP_ID1 Stage Under normal network operation Entities Sensors and gateways

Customization In order to prevent the network from deletion or replacement of security keys, this experiment is utilizing a key repository protected by a strong mechanism to prevent unauthorized access.

Test Pattern ID TP_ID4 Stage Under normal network operation Entities Sensors and gateways

Customization In order to prevent alteration of messages, unique node certificates will be used for the creation of tokens or keys, exchanged over secure communication channel in the form of CoAP-DTLS protocol.


Customization In this experiment, the generic procedure described in section will be followed. The customization only refers to the utilization of CoAP-DTLS as the security measure to prevent the replay attack.


Customization This test pattern includes a successful signature verification process between the gateway (sending an updated version of the software) and the sensor node, as a prerequisite prior to software update installation procedure.

Test Pattern ID TP_ID8 Stage Under normal network operation


Customization To prevent the attacker from intercepting and reading the content of the exchanged messages associated with another entity, the communication will use protocols such as HTTPS or CoAP-DTLS (CoAPS).

Test Pattern ID TP_ID13 Stage Under normal network operation Entities Gateways and Pub/Sub server

32

Customization In order to mitigate this attack, this experiment will utilize cryptographic algorithms not only during the transmission of a message, but also during the storage, preventing potential malicious users from accessing such information.

5.7 EXP VII - Secure IoT platform 5.7.1 Discussion This section provides further details with respect to the security test patterns covered by the IoT platforms, based on the vulnerabilities identified and described in Deliverable 1.1. We work on specification level and thus we focus on the specificities in terms of testing the platform based on the existing specifications (ex. FIWARE and oneM2M), rather on the prevention mechanisms. In addition, to the test pattern customization, during task T1.1 by M12 we will work on establishing a clear link between the security requirements for oneM2M and vulnerability patterns defined in D1.1. 5.7.2 Customization of test patterns Test Pattern ID TP_ID2 Stage Message request Entities Platforms (Servers), Application Entities

Customization The list of sensitive functions supported for the platform is determined, and verification is done that none unauthorized sensitive data is sent when executing these functions. Verifying the misuse of these sensitive functions is also performed.

Test Pattern ID TP_ID4 Stage Message request

Entities Platforms (Servers), Application Entities

Customization

A platform should not allow an alteration of request message from an application entity. A test case that alters a request message according to the defined procedure in the test pattern will be executed using different communication to verify its resistance.

Test Pattern ID TP_ID5 Stage Message request Entities Platforms (Servers), Application Entities

Customization A platform should not allow a replay request message from an application entity. A test case that replays the message without any modification on the different communication protocols will be executed to verify its resistance.


Customization With respect to the kind of database and technologies used for the platform and the platform’s specificities various types of

33

injections could be performed. For instance, SQL Injection, XPath Injection, OS Injection, LDAP Injection etc. Further each type of Injection has subtypes. Thus the test case should iterate over these types and sub-types. The input should be examined for each protocol used for message exchange.


Customization

During message request, a non-authorized entity could request information from the platform from another application entity and being able to read it. For the platform, verifications, would be done for different communication protocols supported by the platform, such as HTTPS or CoAP-DTLS (CoAPS).


Customization

During message request, a non-authorized entity could request information from the platform from another application entity and being able to read it due to configurations, for instance in access control policies. For the platform, verifications would be done for different communication protocols supported by the platform, such as HTTPS or CoA by varying access control policy parameters.


The message request structure has various input parameters. Each of them could contain invalid input. The test cases should examine the structure of the message received by the platform (w.r.t to the protocol used, HTTP, CoaP, etc).

5.8 Summary

To summarise, based on the 14 security test patterns, we have created 42 customizations using the seven experiments. Each vulnerability considered as a threat by the experiments has been covered by the security test patterns. Annex 1 illustrates the coverage of the vulnerabilities by the test patterns and their mapping to the ARMOUR experiments.

34

6 Initial formalisation of test patterns based on models

Within the scope of EXP7: Secure IoT platform we proposed a Model-Based Testing process for security testing in oneM2M using the MBT tool CertifyIt from Smartesting and its extension Test Purpose Language [7]. The CertifyIt tool accepts as input an MBT model, represented by a class diagram, to model the structure of the system under test, and an MBT behavioural modelling language, such as simplified OCL expressions. Based on predefined testing requirements, different test selection criteria could be applied to guide the test generation. The Test Purpose Language is a test selection criterion that could easily capture the test procedure expressed in the security test patterns (defined in Section 3.2). The Test Purpose Language has shown its expression power for vulnerability testing of web applications [8]. The ARMOUR experimentation; for instance, on security IoT platforms, will further help to assess its effectiveness and possibly extend its expression power w.r.t its capacity to cover the ARMOUR security test patterns. The Figure below describes the proposed MBT process for oneM2M security testing. The proposed process starts from the security framework detailed in D1.1 and the library of general vulnerabilities for the four IoT segments.

Figure 3 - Proposed Security Model-Based Testing Process for oneM2M

Based on this database of vulnerabilities and the oneM2M standard’s security documents (TS-003 and TS-0018) oneM2M security test purposes are defined. These test purposes play the role of test patterns. In a second step based on the CertifyIt technology an MBT model for oneM2M is created and the oneM2M security Test Purposes are implemented in the Smartesting Test Purpose Language to drive the test case generation.

35

In order to obtain executable test cases, the generated abstract test cases could be published in an executable format, for instance HTTP requests or in a form of TTCN-3 test cases, as it is the formats retained by oneM2M. Based on the CertifyIt technology it is possible then to create documents for audits purposes. To illustrate the proof of concept, consider for instance the Injection vulnerability (V16) and its corresponding the test pattern (TP_ID10). The test purposes created with CertifyIt will represent the various types of Injection (SQL, LDAP, XPATH etc) and their subtypes.

Figure 4 - Test Pattern Formalisation with Smartesting Test Purpose Language (TP_ID10)

The “for_each” structure allows iterating over each element, and produces the corresponding test cases. The test generation engine will produce one test case for each sub-type. For instance, for the considered types and sub-types of Injection we generated 85 test cases, as depicted in the figure below.

Figure 5 - Injection test cases generated by CertifyIt

36

To conclude this initial work could be a base for the work in the ARMOUR task T2.2. This proof of concept could be used for the other experiments depending on the identified needs.

37

7 Conclusion

Within this first task of the work package 2 we have defined a set of security test patterns that will be used for conception of security test cases in T2.2. These security test patterns were built based on the experiments specific test procedures that have been analysed during T2.1 and in collaboration with T1.1. Based on this analysis, 14 general security test patterns were defined to cover 18 vulnerabilities considered as relevant for the seven experiments (for more details refer to D1.1). The use of these patterns was then customized for each experiment. The benefits of this work are twofold. On one hand it offers general guidelines for testing any element of the four IoT segments (devices and data, applications and services, networks and platforms). On the other hand, the customization of the patterns gives specific guidelines on how to prevent or address the testing procedure specifically for each segment. In addition, the work in T2.1 also gave a proof of concept for test case conception within Experiment 7, which goal is security compliance for IoT. In Experiment 7 we proposed a formalization of the test patterns into the Smartesting Test Purpose Language, a machine readable formal language for test case generation. Its textual representation is easy to read and map to the test patterns. Finally, by the end of T2.1 we will further work on the formalization of the test patterns and possibly the evolution of the security test patterns with respect to the ongoing work on the ARMOUR seven experiments. For this reason, we propose to submit new version of D2.1 by the end of month twelve of the project (M12 – January 2017).

38

8 References

[1] ARMOUR Experiments and Requirements, D1.1, ARMOUR Consortium, May 2016

[2] Initial Security Test Patterns Catalogue. Project Deliverable D3.WP4.T1. DIAMONDS Consortium, 2012-06-30.

[3] RASEN (Compositional Risk Assessment and Security Testing of Networked Systems), http://www.rasenproject.eu/

[4] OWASP Top 10 project. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

[5] Methods for Testing and Specification (MTS); TPLan: A notation for expressing Test Purposes, v1.2.1, ETSI, 2009

[6] M. Schumacher, E. Fernandez-Buglioni, D. Hybertson, F. Buschmann and P. Sommerlad, Security Patterns – Integrating Security and Systems Engineering, Wiley Series in Software Design Patterns, 2006.

[7] J. Botella, F. Bouquet, J.-F. Capuron, F. Lebeau, B. Legeard, F. Schadle: Model-Based Testing of Cryptographic Components - Lessons Learned from Experience.ICST 2013: 192-201

[8] J. Botella, B. Legeard, F. Peureux, A. Vernotte: Risk-Based Vulnerability Testing Using Security Test Patterns. ISoLA (2) 2014: 337-352

[9] Common Criteria. http://www.commoncriteriaportal.org/

[10] A.G Vouffo Feudjio, I. Schieferdecker, A Pattern Language of Test Modelling for Reactive Software Systems, Proceedings of EuroPLoP 2009 - 14th Annual European Conference on Pattern Languages of Programming: July 8-12, 2009, Irsee Monastery, Bavaria, Germany 2009 (CEUR Workshop Proceedings)

[11] CAPEC – Common Attack Pattern Enumeration and Classification. https://capec.mitre.org/

39

9 Annex 1 : Mapping of security test patterns to vulnerabilities

ThetablebelowmapsthesecuritytestpatternstothevulnerabilitiesidentifiedinD1.1andtheircustomizationbythesevenexperimentsinARMOUR:

EXPI. BootstrappingandgroupsharingproceduresEXPII. SensornodecodehashingEXPIII. Securedbootstrapping/joinfortheIoTEXPIV. SecureOS/OvertheairupdatesEXPV. TrustawarewirelesssensorsnetworksroutingEXPVI. SecureIoTServiceDiscoveryEXPVII. SecureIoTplatform

TestPatternID

TestPatternName RelatedVulnerabilities Experiment

I II III IV V VI VIITP_ID1 Resistance to an unauthorized access,

modificationordeletionofkeysV1,V2,V3,V4,V5 X X X X

TP_ID2 Resistance to the discovery of sensitivedata

V6 X X

TP_ID3 Resistance to software messagingeavesdropping

V7 X

TP_ID4 Resistancetoalterationofrequests V8 X X X X X X

TP_ID5 Resistancetoreplayofrequests V9 X X X X X X

TP_ID6 Rununauthorizedsoftware V10 X X X X X

TP_ID7 Identifying security needs depending ontheM2Moperationalcontextawareness

V12 X

TP_ID8 Resistancetoeavesdroppingandmaninthemiddle

V13 X X X X X

TP_ID9 Resistance to transfer of keys via of thesecurityelement

V14 X X X

TP_ID10 ResistancetoInjectionAttacks V16 X

TP_ID11 Detection of flaws in the authenticationandinthesessionmanagement

V17 X X

TP_ID12 Detectionofarchitecturalsecurityflaws V18 X X

TP_ID13 Detection of insecure encryption andstorageofinformation

V19 X X X

TP_ID14 Resistancetoinvalidinputdata V20 X

Deliverable D2.1 Generic test patterns and test models for ... · oneM2M structure and the oneM2M...

Documents

Transcript of Deliverable D2.1 Generic test patterns and test models for ... · oneM2M structure and the oneM2M...