H2020-EUJ-02-2016
H2020 Grant Agreement Number 723076
NICT Management Number18302

Deliverable D5.2

User Empowerment
Architectural
Version V1.0
September 30th, 2017
ABSTRACTThis deliverable integrates the work of task 5.1 and 5.2 with the objective ofintegrating the components definition from the former task with the proposedmechanism for privacy preserving defined in the latter task. This mechanism
uses an attribute-based encryption (ABE) technique to provide security over thebroadcast data allowing only the users with the right credentials to decrypt suchinformation.
Such components are presented through a functional perspective providing anarchitectural vision of the approach provided in the project for the user
empowerment.
In addition, in this document we also provide a section aimed at providing how
the security components interact among them with the target of providing such
empowerment to the users of our CPaaS.io platform. Such interactions arepresented in this deliverable through different sequence diagrams where thetransmitted information is roughly described. Furthermore, we present the
Omotenashi platform which allows access to multiple IoT services via a single
user token based on discretionary principles.
Finally, we provide different use cases with common operations that can be
carried out by different kind of users so as to shed some light onto the use of
the platform and the mission of each defined component.

This work is licensed under the Creative Commons Attribution 4.0 International License.
To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/.

Deliverable D5.2

User Empowerment Architectural

Disclaimer
This document has been produced in the context of the CPaaS.io project which is jointly funded by theEuropean Commission (grant agreement n° 723076) and NICT from Japan (management number 18302).
All information provided in this document is provided "as is" and no guarantee or warranty is given thatthe information is fit for any particular purpose. The user thereof uses the information at its sole risk andliability. For the avoidance of all doubts, the European Commission and NICT have no liability in respectof this document, which is merely representing the view of the project consortium. This document issubject to change without notice.

Document Information
Editors

Antonio Skármeta, Juan A. Martínez

Authors

Juan A. Martínez, Agustín Cánovas, Antonio Skármeta, Fahim Khan

Reviewers

François Carrez (UoS)

Delivery TypeR

Dissemination
Level

PublicContractual
Delivery Date

September 30, 2017

ActualDelivery Date

September 30, 2017

Keywords

Access Control, Privacy, Authorization, Privacy, Consent Management,
Personal Data Store

H2020 EUJ-02-2016

CPaaS.io

Page 2 of 48

Deliverable D5.2

User Empowerment Architectural

Revision History
Rev.

Date

Description

Contributors

0.1

04.08.2017

ToC proposal

Juan A. Martínez, Agustín Cánovas, Antonio
F. Skármeta

0.2

01.09.2017

First contribution on
Security Components

Juan A. Martínez, Agustín Cánovas, Antonio
F. Skármeta

0.3

11.09.2017

Use Case scenarios

Juan A. Martínez, Agustín Cánovas, Antonio
F. Skármeta

0.4

14.09.2017

First Draft

Juan A. Martínez, Agustín Cánovas, Antonio F.
Skármeta

0.5

20.09.2017

Final definition of Use
Case scenarios

Juan A. Martínez, Agustín Cánovas, Antonio F.
Skármeta

0.6

27.09.2017

eTRON contribution

Fahim Khan

0.7

28.09.2017

Compilationdeliverable

0.8

30.09.2017

Review

François Carrez

1.0

30.09/2017

Delivery to EC

Stephan Haller

H2020 EUJ-02-2016

ofCPaaS.io

Juan A. Martínez, Agustín Cánovas, Antonio F.
Skármeta

Page 3 of 48

Deliverable D5.2

User Empowerment Architectural

Table of Contents
1

Introduction ................................................................................................................................................................. 8

2

Empowerment Components Functional View................................................................................................. 9

2.1

Authentication ........................................................................................................................................................... 9

2.2

Authorization .............................................................................................................................................................. 9

2.3

Identity Management............................................................................................................................................ 10

2.4

Privacy/Secure Group Sharing ........................................................................................................................... 10

3

Identity Management ............................................................................................................................................. 12

4

Authorization ............................................................................................................................................................. 15

4.1

Policy-based Access Control .............................................................................................................................. 16

4.2

Capability-based Access Control ...................................................................................................................... 21

5

Privacy/Secure Group sharing ............................................................................................................................. 23

6Interaction of components ................................................................................................................................... 25

6.1

Identity Management............................................................................................................................................ 25

6.2

Authorization request/response ....................................................................................................................... 26

6.3

Privacy/Security Group sharing ......................................................................................................................... 27

7

Use Cases ................................................................................................................................................................... 30

7.1

Environmental monitoring .................................................................................................................................. 30

7.2

Aggregated Traffic Data Visualization ............................................................................................................ 32

8

IoT Service Integration through eTRON Architecture and Omotenashi Platform........................... 36

8.1

eTRON ......................................................................................................................................................................... 36

8.2

Omotenashi Platform ............................................................................................................................................ 41

9Conclusions ................................................................................................................................................................ 45

10References .................................................................................................................................................................. 46

H2020 EUJ-02-2016

CPaaS.io

Page 4 of 48

Deliverable D5.2

User Empowerment Architectural

List of Figures
Figure 1: Context-based partial identity selection and authentication...................................................................... 12
Figure 2: Identity Selection sequence diagram ................................................................................................................... 13
Figure 3: XACML Policy Language Model ............................................................................................................................. 17
Figure 4: XACML standard overview ....................................................................................................................................... 18
Figure 5: PAP Main View .............................................................................................................................................................. 19
Figure 6: Generalization of the AttributeID .......................................................................................................................... 19
Figure 7: Defining different Attributes ................................................................................................................................... 20
Figure 8: Diagram of DCapBAC operation ............................................................................................................................ 22
Figure 9: Context-aware group sharing ................................................................................................................................. 23
Figure 10: Relationship between sharing policies and CP-ABE policies .................................................................... 24
Figure 11: IoT Service Request with Privacy-Preserving Authentication ................................................................... 25
Figure 12: Authorization process.............................................................................................................................................. 27
Figure 13: Secure Group Sharing.............................................................................................................................................. 28
Figure 14: Environmental monitoring use case component interaction ................................................................... 31
Figure 15: Traffic sensor/sign registration ............................................................................................................................ 33
Figure 16: Request device list .................................................................................................................................................... 34
Figure 17: Requesting / subscribing to traffic data ........................................................................................................... 35
Figure 18: eTRON and Omotenashi Platform in the overarching u2 Arch. .............................................................. 36
Figure 19: eTRON Hardware Module...................................................................................................................................... 37
Figure 21: eTRON Session Establishment Protocol ........................................................................................................... 38
Figure 23: The Omotenashi cloud aggregates a variety of services on a single platform.................................. 42
Figure 24: Architectural Overview of the Omotenashi Cloud Platform ..................................................................... 43

List of Acronyms
Acronym

Meaning

6LBR

6LowPAN Border RouterAA

Attribute Authority

ABAC

Attribute-Based Access Control

ABE

Attribute-Based Encryption(D)CapBAC

Capability-Based Access Control

CoAP

Constrained Application Protocol

H2020 EUJ-02-2016

CPaaS.io

Page 5 of 48

Deliverable D5.2

User Empowerment Architectural

Acronym

Meaning

CP-ABE

Cyphertext-Policy Attribute-Based Encryption

CRM

Customer Relationship Management

CT

Capability Token

ECDSA

Elliptic Curve Digital Signature AlgorithmeTP

entity Transfer Protocol

HTTP

HyperText Transfer Protocol

IBE

Identity-Based Encryption

ID

IDentifier

IdM

Identity Management

IoT

Internet of Things

JSON

JavaScript Object Notation

KEM

Key Exchange & Management

PAP

Policy Administration Point

PDP

Policy Decision Point

PDS

Personal Data StorePEP

Policy Enforcement Point

PIP

Policy Information Point

PKC

Public Key Cryptography

PKI

Public Key Infrastructure

RBAC

Role-Based Access Control

SAML

Security Assertion Markup Language

SKC

Symmetric Key Cryptography

SSO

Single Sign On

TS Wrapper

Traffic Safe WrapperUC

Use Case

UML

Unified Modeling Language

H2020 EUJ-02-2016

CPaaS.io

Page 6 of 48

Deliverable D5.2

User Empowerment Architectural

Acronym

Meaning

VRM

Vendor Relationship Management

XACML

eXtensible Access Control Markup Language

ZBAC

AuthoriZation-Based Access Control

H2020 EUJ-02-2016

CPaaS.io

Page 7 of 48

Deliverable D5.2

User Empowerment Architectural

1 Introduction
This second WP5 deliverable is a continuation to the previous deliverable, D5.1 [1], of this WP. This
document encompasses all the work defined in task 5.1 and 5.2 presenting the different security
components integrated into the CPaaS.io platform with the objective of controlling the access to theinformation and providing a mechanism for privacy preserving which has been defined during task 5.2.
Additionally, this information is presented from a different point of view, more pragmatic and functional.
CPaaS.io must is presented not only as a single City Platform which is applied to a concrete city, but it
introduces the idea of exchanging and integrating information from inter-cultural platforms throughstandard interfaces. Such information can be sensitive in many cases because of its nature and therefore
security mechanisms which guarantees the proper access to the information by the users with the rightcredentials must be adopted.
Authentication, authorization, identity management as well as security group sharing mechanisms arefunctionalities which are handled by our platform. Starting from those security properties and necessities
this deliverable is developed encompassing the different technologies employed to fulfil such security
objectives.
Authentication is a property tightly related to registration of users into a system, for this reason the
Identity Management component is responsible for managing this issue. Authorization is granted thanks
to two different approaches: a policy based scheme based on XACML and using a Capability-Based
Access Control approach (CapBAC) which employs Capability Tokens which are self-contained security
authorization elements easy to validate. Finally, we present a mechanism aimed at preserving the privacy
based on Attribute-Based Encryption (ABE) which is applied to the information transmitted to a group of
consumers which allow the authorized ones to reveal such information.
The functional point of view of the components is also one objective of this deliverable. For this reason,
we provide a pragmatic view of the interaction of the different components in order to guarantee thedifferent security properties.
A section entitled Use Cases (UC) presents several use cases for different purposes which exemplify thedifferent security components interactions by a more realistic point of view providing more concrete
information and detail about such interactions.
Finally, the last section of this document corresponds to the Conclusion section where we summarize all
the work carried out in this deliverable providing also some new future ways which could be taken as
future steps for this project.

H2020 EUJ-02-2016

CPaaS.io

Page 8 of 48

Deliverable D5.2

User Empowerment Architectural

2 Empowerment Components Functional View
In the previous deliverable D5.1 we started the definition of the security components responsible forproviding access control and authorization to the CPaaS.io platform. In this document we provide a
different approach; we motivate the use of those components and also provide more details from thefunctional point of view. Following this point of view, we have different security properties that areprovided by our platform: authentication, authorization, identity management and privacy oriented togroup sharing communication.
Let us describe them in the following paragraphs.

2.1 Authentication
Authentication ensures that an identity of a subject (user or smart object) is valid, i.e. that the subject is
indeed who or what he/it claims to be. It allows binding an identity to a subject. The authentication canbe performed based on something the subject knows (e.g. password), something the subject possesses(e.g. smart cards, security token) or something the subject is (e.g. fingerprint or retinal pattern).
The authentication module enables authenticating users and smart objects based on the provided
credentials. The credential can be in form of login/password, shared key, digital certificate. As a result of
the authentication process, an assertion is generated to be used afterwards, in order to declare that a
specific subject was authenticated successfully by the Issuing authority.
Traditional authentication mechanisms based on for instance login-password or electronic IDs have beenaddressed and solved in the past for different ICT computing paradigms and scenarios. Indeed, it has
also been addressed in IoT projects, thereby some IoT platforms already support such basic
authentication mechanisms. That is why CPaaS.io focuses on alternative and more sophisticated ways of
performing authentication ensuring, at the same time, privacy and minimal disclosure of attributes. Thus,
this kind of alternative privacy-preserving way of authentication using anonymous credential system ishandled in CPaaS.io framework by the Identity Management (IdM) component. The IdM is able to verify
anonymous credential and then, in case the identity is proved, the IdM interacts with the authentication
module which is the one that actually delivers authentication assertion to be used during a transaction.
The Identity Management system is described in deep in Section 3 of this document.

2.2 Authorization
The inherent requirements and constraints of IoT environments, as well as the nature of the potential
applications of these scenarios, have brought about a greater consensus among academia and industry
to consider access control as one of the key aspects to be addressed for a full acceptance of all IoT
stakeholders.
The proposed authorization system is based on a combination of different access control models andauthorization techniques, in order to provide a comprehensive solution for the set of consideredscenarios. Specifically, we employ two different technologies: one is based on the use of access control
policies to make authorization decisions, and the other employs authorization tokens as an access
control mechanism to be used by IoT devices as well as the resources stored in our CPaaS.io platform.

H2020 EUJ-02-2016

CPaaS.io

Page 9 of 48

Deliverable D5.2

User Empowerment Architectural

In this regard, standards such as SAML [2] and XACML [3] could be adopted; nonetheless, it is desirable
to employ access control solutions specially tailored to IoT scenarios. In this sense, our security
components can perform capability-based access control based on the mechanism presented in [4]. It
describes authorization tokens specified in JSON and ECC optimizations to manage access control on
constrained devices.
This module is explained in more detail in Section 4.

2.3 Identity Management
Identity Management encompasses the technologies and processes aimed at controlling and managing
the private and secure access to the information and resources while protecting, at the same time, theuser or smart object profiles. The IdM should provide means to storing information of entities such as
identifiers, credentials and pseudonyms. It is also responsible for defining, managing and issuing theidentities and credentials of entities, taking into account that in IoT environment an entity can refer toboth peoples and smart objects.
IdM systems usually provide interfaces to make identity information and management accessible forboth users and administrators. It is desirable that the system itself is distributed and resilient, achieving at
the same time, high-performance results. This last consideration is of special interest in IoT, where the
IdM system can be deployed in devices and gateways having constrained hardware capabilities.
Traditional Identity Management systems lack of proper means to dealing with privacy-preserving andusually do not provides means for their users to deal with minimal disclosure of private information.
In traditional IdM systems using common credentials, the Service Provider can usually store all the tokens
and users’ credential (e.g. X.509 certificates) that are presented to it. The problem is that the service
provider can then link them together. Thus, users should be given full control over their data in order todetermine which private data is disclosed in which context. The IdM should provide a proper mechanism
to manage their partial identities in a private way according to the context, i.e. providing anonymity andunlinkability. We detail this component in Section 3.

2.4 Privacy/Secure Group Sharing
The realization of scenarios with entities composing dynamic communities requires the definition of
appropriate mechanisms in order to design a scalable and distributed security solution for the envisioned
use cases. Unlike current Internet, in such dynamic coalitions, IoT interaction patterns are often based on
short and volatile associations between entities without a previously established trust link. Providing
basic security properties to such data exchange is a paramount security issue; It needs to be properly
addressed by allowing more flexible sharing models (beyond the classic request/response approach), as
well as fleeting and dynamic associations between entities, while privacy of involved entities is stillpreserved.
Because of the usage of resource-constrained devices, Symmetric Key Cryptography (SKC) has been
widely used in IoT, requiring that producer and consumer share a specific key. Nevertheless, thisapproach is not able to provide a suitable level of scalability and interoperability in a future with billionsof heterogeneous smart objects. These issues are tackled by Public Key Cryptography (PKC); however KPC
presents significant higher computing and memory requirement as well as the need to manage thecorresponding certificates. A common feature with SKC is that PKC allows a producer to encrypt
information to be accessed only by a specific consumer. However, given the pervasive, dynamic andH2020 EUJ-02-2016

CPaaS.io

Page 10 of 48

Deliverable D5.2

User Empowerment Architectural

distributed nature of IoT, it is necessary to consider different scenarios in which some information can beshared with a group of consumers or a set of unknown receivers and, therefore, not addressable a priori.
In that sense, Identity-Based Encryption (IBE)[5] was designed as an alternative without certificates to PKC,
in which the identity of an entity is not determined by a public key, but a string. Consequently, it enables
more advanced sharing schemes since a data producer could share data with a set of consumers whose
identity is described by a specific string. In this direction, Attribute-Based Encryption (ABE) [6] represents
the generalization of IBE, in which the identity of the participants is not represented by a single string,
but by a set of attributes related to their identity. Just as IBE, it does not use certificates, while
cryptographic credentials are managed by an entity usually called Attribute Authority (AA). In this way,
ABE provides a high level of flexibility and expressiveness, compared to previous schemes. In ABE, a pieceof information can be made accessible to a set of entities whose real, probably unknown identity, isbased on a certain set of attributes.
Based on ABE, in a Cyphertext-policy Attribute-based Encryption(CP-ABE) scheme [7], a ciphertext isencrypted under a policy of attributes, while keys of participants are associated with sets of attributes. In
this way, a data producer can exert full control over how the information is disseminated to otherentities, while a consumer’s identity can be intuitively reflected by a certain private key. Moreover, inorder to enable the application of CP-ABE on constrained environments, the scheme could be used in
combination with SKC. Thus, a message would be protected with a symmetric key, which, in turn, would
be encrypted with CP-ABE under a specific policy. In the case of smart objects cannot apply CP-ABE
directly, the encryption and decryption functionalities could be realized by more powerful devices, suchas trustworthy gateways. In addition, CP-ABE can rely on IdM systems (e.g. anonymous credentials
systems) to obtain private keys associated to certain user’s attributes from a specific AA, after
demonstrating the possession of such attributes in the partial identity. Then, these private keys can beused by consumers to decrypt data which is disseminated by producers, as long as the consumer satisfies
the policy which was used to encrypt that data.

H2020 EUJ-02-2016

CPaaS.io

Page 11 of 48

Deliverable D5.2

User Empowerment Architectural

3 Identity Management
The Identity Management component of the security framework is an anonymous credential system that
ensures user privacy and minimal disclosure of personal information when accessing IoT services. It isbased on already existing implementations of anonymous credential system like Idemix [8] or U-Prove[9]. It is however adapted to IoT and Smart City scenarios in order to address the security requirements of
CPaaS.io platform which can also imply that users employ their smartphones to access such information.
Having part of the IdM deployed in end-users’ smartphones allows to control and manage personal datain the smartphone, defining partial identities and describing rules defining the way her personal
information is disclosed according to the context. In this kind of scenarios, users could interact directlywith others peers member of communities and bubbles to share information and access each other IoT
services, so that user devices could act as consumers and producers of information. It means that theIdM deployed in the device should provide means to select the partial identity according to actual
context, and run the presentation process to demonstrate its anonymous credentials without revealing
unnecessary private information.
The IdM component, unlike traditional identity management systems, addresses a small set offunctionalities, focusing on the authentication process and the privacy preserving mechanism that enable
users to use different partial identities to access target devices according to the context. Other IdM
functionalities used in traditional web contexts, such as user profile management and Single Sign On(SSO), are left out of the scope of this project to open existing solutions, which already successfully
provide those functionalities.

Figure 1: Context-based partial identity selection and authentication

H2020 EUJ-02-2016

CPaaS.io

Page 12 of 48

Deliverable D5.2

User Empowerment Architectural

Figure 1 above shows the way the partial identity selection as well as the authentication based onanonymous credential system is done by our IdM component. The authentication is carried out by
running the presentation process.
As can be seen in this figure, prior performing the authentication, the user or smart object can have rules
defined to choose the most suitable partial identity (i.e. credential) to use in each particular context. To
perform the Identity selection, the Identity selector is notified by the context manager each time aparticular context has changed. It is done by snooping to the context rules the Identity Selector isinterested in.
It should be noticed that the Context Manager could have obtained the context information from both,an external context provider (like the context broker), or taking into account only device local context
information.
3.1.1 Sequence Diagram
This section describes the privacy-preserving IdM process about adopting the proper partial identity
according to the context, in order to authenticate against a target device using such a partial identity,
ensuring minimal disclosure of private data. The sequence diagram in Figure 2 below shows the overall
process:

Figure 2: Identity Selection sequence diagram

In a first stage, a subject or consumer wants to access a protected target device acting as producer. First,
the subject wants to select the proper partial identity (i.e. the anonymous credential) to use against thetarget device, in the actual context. To this aim, the IdM selector on an event of new request, priorrunning the identity privacy rules to select the most suitable credential, obtains the context relying on
the Internal Context Manager of the device (step 2). In step 3 to 5 the context manager checks context
values obtained directly from the own device measurements. In addition, the context manager can be
H2020 EUJ-02-2016

CPaaS.io

Page 13 of 48

Deliverable D5.2

User Empowerment Architecturalconfigured to access (either subscription or request/response) to an external context broker where
context data from other trusted devices and users are maintained. This interaction is based on NGSI
standard as explained in previous section. Then, the Context Manager unifies its own context and values
coming from the context broker and passes this information to the IdM Selector (step 6). The IdM Selector
evaluates the privacy identity rules (step 7), which take into account the context, to choose the best
partial identity to adopt in such a situation.
It should be noticed that the partial identity selection process can be done also later on, during thepresentation process (step 9), instead of performing it at the beginning. In such a case, the Identity
Selector could also take into account the requirements from the target device regarding the attributes tobe contained in the anonymous credential.
In the second stage (starting from step 9) the subject uses the selected anonymous credential to obtain
the data from the target device B. To this aim, the subject must be authenticated using the anonymous
credential and following the presentation process. As a result, in case of a successful authentication, theauthorization stage takes place, which decides to allow subject A to access the requested
resource/service.

H2020 EUJ-02-2016

CPaaS.io

Page 14 of 48

Deliverable D5.2

User Empowerment Architectural

4 Authorization
Because of the heterogeneous nature of IoT devices and networks, most of the recent access control
proposals have been designed through centralized approaches in which a central entity or gateway is
responsible for managing the corresponding authorization mechanisms, allowing or denying requests
from external entities. Since this component is usually instantiated by unconstrained entities or back-end
servers, standard access control technologies are directly applied. However, significant drawbacks arise
when centralized approaches are considered on a real IoT deployment which involves by essence
constrained entities.
On the one hand, the inclusion of a central entity clearly compromises end-to-end security properties,
which is considered an essential requirement [10] on IoT, because of the sensitivity level of potential
applications. On the other hand, the dynamic nature of IoT scenarios with a potential huge number ofconnected devices complicates the access controls management with the central entity, affecting
scalability. Moreover, access control decisions do not consider contextual conditions which are locallysensed by end-devices.
These issues could be addressed by a distributed approach, in which constrained devices (e.g. sensors,
actuators) are able to make authorization decisions without the need to delegate this task to a different
entity. In this case, end-devices are enabled with the ability to obtain, process and transmit information
to other entities in a protected way. However, in a fully distributed approach, the feasibility of theapplication of traditional access control models, such as Role-Based Access Control (RBAC) or AttributeBased Access-Control (ABAC), has not been demonstrated so far. Indeed, as previously mentioned, suchmodels require a mutual understanding of the meaning of roles and attributes, as well as complex access
control policies, which makes challenging the application of them on resource-constrained device. In thatsense, it is necessary to consider the amount of computational resources which can be available on theend-device, since it may not be sufficient to apply a complex access control mechanism. Moreover, theimpact of the potential applications of IoT in all aspects of our lives is shifting security aspects from anenterprise-centric vision to a more user-centric one. Therefore, usability becomes a key factor to beconsidered, since untrained users must be able to control how their devices and data are shared withother users and services.
Recently, the Capability-Based Access Control model (CapBAC) has been postulated as a realistic andpromising approach to be deployed on IoT scenarios [11]. Inspired by SPKI Certificate Theory [12] andauthoriZation-Based Access Control (ZBAC) [13] foundations, CapBAC provides significant advantages
over more established approaches by providing support for least privilege and preventing security
problems such as the Confused Deputy problem [15]. Additionally, CapBAC simplifies user managementtasks since the definition of complex policies is not required. The key element of CapBAC is the conceptof capability, which was originally introduced by [14] as "token, ticket, or key that gives the possessor
permission to access an entity or object in a computer system". This token is usually composed by a setof privileges which are granted to the entity holding the token.
In a typical CapBAC scenario, an entity (subject) tries to access a resource of another entity (target).
Usually, a third party (issuer) generates a token for the subject specifying which privileges it has. Thus,
when the subject attempts to access a resource hosted in the target, it attaches the token which was
generated by the issuer. Then, the target evaluates the token, granting or denying access to the resource.
Therefore, a subject which wishes to get access to some information from a target, requires sending thetoken attached to the request. Thus, the target that receives such a token already knows the privileges
H2020 EUJ-02-2016

CPaaS.io

Page 15 of 48

Deliverable D5.2

User Empowerment Architecturalthat the subject has; only a local Policy Decision Point (PDP) further needs to verify the validity of thecapability token. This procedure simplifies the access control mechanism, and happens to be a relevant
feature in scenarios with resource-constrained devices since complex access control policies are notrequired to be deployed on constrained end-devices.
Additionally, the token must be tamper-proof and unequivocally identified in order to be considered in areal environment. Therefore, it is necessary to consider suitable cryptographic mechanisms to be usedeven on resource-constrained devices which enable an end-to-end secure access control mechanism.
Moreover, given its high level of flexibility, CapBAC could be also extended to consider contextual
conditions related to parameters which are locally sensed by end-devices. Also, this model could becomplemented with other access control models by providing automated tools to infer the privileges tobe embedded into the token.

4.1 Policy-based Access Control
The eXtensible Access Control Markup Language (XACML) [3] is a standard, declarative and XML-based
language to express access control policies, which allows specifying the set of subjects which canperform certain actions on a specific set of resources, based on their attributes. Under the XACML data
model, the definition of access control policies is mainly based on three elements: PolicySet, Policy andRule.
A PolicySet may contain other PolicySets and Policies, whereas a Policy includes a set of Rules, specifying
an Effect (Permit or Deny), as a result of applying that Rule for a particular request. The Target sections ofthese elements define the set of attributes from resources, subjects, actions and environment to which the
PolicySet, Policy or Rule are applicable.
Moreover, since different Rules might be applicable under a specific request, XACML defines Combining
Algorithms in order to reconcile multiple decisions. In addition, a set of obligations (Obligations class)can be used to notify a set of actions to be performed related to an authorization decision.
Figure 3 below presents the XACML Policy Language Model as explained in the previous paragraphs.

H2020 EUJ-02-2016

CPaaS.io

Page 16 of 48

Deliverable D5.2

User Empowerment Architectural

Figure 3: XACML Policy Language ModelXACML architecture consists mainly of four elements:

Policy Administration Point (PAP): it is used to create a policy or set of policies;
Policy Decision Point (PDP): it evaluates applicable policies and makes authorization decisions;
Policy Information Point (PIP): it acts as a source of attribute values;
Policy Enforcement Point (PEP): it is responsible for performing access control, by making decision
requests and enforcing authorization decisions.

Finally, the main interactions between these components under XACML standard are shown in Figure 4.

H2020 EUJ-02-2016

CPaaS.io

Page 17 of 48

Deliverable D5.2

User Empowerment Architectural

Figure 4: XACML standard overview

In light of this diagram, we can see that the different security policies which must prevail over a certain
system are defined by the PAP (1. Define policy). When a certain service request accesses to a specificresource, it must issue a request message (2. Request resource). This request arrives to the PEP which is
the one which executes the security policies and grants/denies the access to the resource to the service
depending on them. To do so, it forwards the service request (3. Forward request) to the PDP.
Nevertheless, the PDP could need extra information in order to make the security decision; this is thereason why a Context Handler is the central element of this diagram. It will receive each request (3 – 11)
and forward it to the specific component the purpose of which is to provide all needed information to
the PDP to generate the security response associated to the message 3. Finally, such response is received
by the PEP which enforces the security policy to the initial resource request.

4.1.1 Policy Administration PointAs described below, the PAP is responsible for generating the different security policies. The Figure 5
below presents a Web interface which is used by the security administrator to define the XACML security
policies.

H2020 EUJ-02-2016

CPaaS.io

Page 18 of 48

Deliverable D5.2

User Empowerment Architectural

Figure 5: PAP Main View

It counts with two administration sections (left panel): the first one to define security policies and thesecond one to define the different attributes that are managed by the former ones. In addition, there aresome configuration aspects (right panel) that can be modified by the last button.
The figure 6 shows the relation between Subject, Resource and Action attributes generation, defining
them as generic pieces that will shape the policies. These generic attributes are created implementing
any predefined or even customized XACML AttributeIDs that will enrich the expressiveness of the policies.

Figure 6: Generalization of the AttributeID

In this sense the possibility of defining customized policies has been increased and, furthermore, the useof XACML obligations has been also considered and implemented as part of the policy definition that will
be used when generating Capability Tokens. This way, the Capability Manager will be informed about the
lifetime of the token associated with the specific policy.
H2020 EUJ-02-2016

CPaaS.io

Page 19 of 48

Deliverable D5.2

User Empowerment Architectural

Figure 7: Defining different Attributes

Once the attributes for a Resource are defined, the attributes for Subjects and Actions can be specified
too (see Figure 7 above).
A policy contains rules that express the actions that are allowed or denied. For instance, we can create apolicy with one rule and specify the resource it is referring to, what action can be performed with that
resource and the subject that is allowed to do that.
With the specified policies, a request can be made to the PDP that has the location of the policies. The
PDP evaluates the request to decide PERMIT or DENY, returning the corresponding Obligation, if any,
when supported.
The request is sent encoded in JSON [16], which provides a less verbose representation of theinformation than other formats like XML, and improves the request processing as well. If such request is
successfully resolved, the PDP will return a response in the form of {“Result”:”Permit”}.
Regarding its implementation, the PDP is deployed as a web service to be accessed by the entity acting
as a PEP through the exchange of HTTP messages with JSON payloads containing the XACML requests or
responses.

4.1.2 Policy Decision Point
The PDP is based on web technologies to make a scalable and lightweight solution. This PDP can beapplied to any large scale deployment that requires XACML as policy language.
The PDP evaluates XACML policies in XML representation. However, the requests are sent in JSON
format, which improves the comprehension and the performance in the exchanging of requests andresponses. In [17] a comparison of the XACML PDP and other PDP solutions are performed. This
H2020 EUJ-02-2016

CPaaS.io

Page 20 of 48

Deliverable D5.2

User Empowerment Architecturalcomparison shows that XACML PDP achieves the performance improvements over existing solutions interms of scalability and efficiency.

4.2 Capability-based Access Control
This section describes a capability-based access control solution that supports constrained IoT devices inlarge deployments of Smart Cities. Since typical IoT end-devices present severe resource constraints,
most of proposals have addressed this problem by using centralized approaches where a central entity or
gateway is responsible for managing the corresponding authorization mechanisms and security
protocols.
While popular access control models, such as RBAC [18] or ABAC [19], and security standard technologies
and protocols can be used in these scenarios, several drawbacks arise when they are considered in a real
IoT deployment. First, the inclusion of a central entity clearly compromises end-to-end security
properties. Second, scalability of these solutions is quite doubtful since trust with this central entity must
be properly managed by information providers and consumers. Third, authorizations decisions are notbased on information which is locally sensed by IoT end-devices. Finally, traditional access control
models lack flexibility, usability, and easy management for environments with billions of heterogeneous
devices that are managed by non-expert users.
In contrast, our proposal makes use of capability-based access control model, whose description,
motivation and advantages against other models for IoT scenarios can be found in [20]. In addition, ourwork is based on technologies specifically designed for IoT environments, facilitating a distributed
approach in which smart things themselves can make fine-grained authorization decisions. These
decisions are based on local conditions, providing context-awareness in the authorization process.
Moreover, our work suggests the use of Public Key Cryptography whose characteristics fit therequirements of IoT regarding scalability and interoperability. For PKC, our highly optimized version of
Elliptic Curve Digital Signature Algorithm (ECDSA) is implemented in constrained IoT devices to ensure
end-to-end authentication, integrity and non-repudiation, without the intervention of any intermediate
entity.

4.2.1 Distributed CapBAC operation
The basic operation of our proposed DCapBAC is shown in the Figure 8. Below, we clarify the different
steps of the access control process.

H2020 EUJ-02-2016

CPaaS.io

Page 21 of 48

Deliverable D5.2

User Empowerment Architectural

Figure 8: Diagram of DCapBAC operation

Issue Capability Token (0.): As initial step, the Issuer entity, usually instantiated by the device
owner, issues a capability token to the Subject to be able to access that device. Additionally, inorder to avoid security breaches, the Issuer signs this token by using ECDSA, whose value isattached to the capability token. Actually, it is noteworthy that this stage requires an access
control process, whereby a set of permissions are inferred and granted to the Subject. The
process of how to generate the token is outside the scope of this document. For example, insome contexts, the generation of this token might require a previous authentication process
between Issuer and Subject. Conversely, in other IoT scenarios, this token might be sent only tosubject which meet certain contextual conditions, e.g., based on geolocation;

Access Request (1.): Once the Subject has received the capability token, it attempts to access thedevice. For this purpose, it generates a CoAP [21] request, in which the token is attached. The
inclusion of the token into the request has been carried out using the payload field, and theContent-Format header to indicate the representation format of the payload inside the request. In
addition, the Request-Uri option is used to indicate the specific resource to be accessed in the
Device. Finally, the Subject also signs the CoAP request itself using ECDSA algorithm, whose value
is attached to that message by adding a new header called Signature.

Following this diagram, the request does not have to be read by any intermediate entity. In fact, theentity which is denoted as gateway could be instantiated by a 6LowPAN Border Router (6LBR) with only
basic routing functionalities.


Get Authorization Decision (2.): When the Device receives the access request, the authorization
process is carried out (3.). First, the application checks the validity of the token as well as therights and conditions to be verified. Then, due to the cost of these operations, the Issuer
signature is verified and Subject is authenticated. A more detailed description of this process isgiven in [22].

Return Authorization Decision (4. then 5.). Finally, once the authorization process has been
completed, the Device generates a CoAP response based on the authorization decision. In thecase of an unauthorized request, an Unauthorized 4.01 response is returned, indicating that the
Subject is not authorized to perform the requested action. Otherwise, the value of the answer will
depend on the content of the request.

H2020 EUJ-02-2016

CPaaS.io

Page 22 of 48

Deliverable D5.2

User Empowerment Architectural

5 Privacy/Secure Group sharing
Our Group Manager component is based on the use of the Ciphertext Policy Attribute Based Encryption(CP-ABE) [7] cryptographic scheme in order to enable a secure data sharing mechanism with groups ofentities (i.e. communities and bubbles of smart objects. The following Figure 9 shows how contextual
information from the Context Manager of a subject entity (acting as an information producer) is used by
the Group Manager to select a specific CP-ABE policy in order to encrypt a specific information.
Specifically, the Group Manager contains a set of Sharing Policies how the information is disseminatedaccording to contextual data. These policies are evaluated by the Group Sharing engine before
information is disseminated by the subject. The result of the evaluation of these policies is, in turn, a CPABE policy, which is employed by the CP-ABE engine to encrypt the information with that policy.
After the information is encrypted and disseminated, the Group Manager of a target entity (acting as aconsumer) will try to decrypt it with CP-ABE keys related to its identity attributes through its CP-ABE
engine.

Figure 9: Context-aware group sharing

Figure 9 shows an overview of the main components of the Security Framework required when the
secure group sharing takes place between a producer and consumer. As it can be seen, in the producer
side the Group Manager evaluates the sharing policies considering the Context handled by the local
Context Manager, which in turn, can interact with the Context broker. As a result of the sharing policies
evaluation, a CP-ABE policy is selected to encrypt the data, which is then delivered securely to theconsumer(s).
H2020 EUJ-02-2016

CPaaS.io

Page 23 of 48

Deliverable D5.2

User Empowerment Architectural

5.1.1 Sharing policies
Sharing Policies According to the previous description, the Group Manager component has a set ofgroup-sharing policies which are evaluated before information is disseminated and intended to beshared with a community or bubble of smart objects.
These policies specify particular contextual conditions which are needed to satisfy a certain sharing
policy. The result of these policies is, in turn, a CP-ABE policy indicating the set of entities which will beenabled to decrypt the information to be shared. As for the Identity Selector, the group sharing policies
can be defined by making use of a rule-based tool that allows describing the context information.
This sub-component can be also used by high-level graphical applications that can facilitate users thedefinition of rules to be integrated into the set of sharing policies. The relationship between sharing
policies and CP-ABE policies is shown Figure 10.

Group Sharing Policies evaluation

Both sets of policies are within the Group Manager component of the device. According to it, when asharing policy is successfully evaluated, the resulting CP-ABE policy is used to encrypt the information to
be shared, and consequently sent to the CP-ABE engine sub-component. In the case where two (or more)sharing policies are successfully evaluated, the most restrictive CP-ABE policy could be selected.

Group Sharing Policies

CP-ABE policies

Group Sharing Policy 1

CP-ABE policy 1
CP-ABE engine

Group Sharing Policy 2Group Sharing Policy 3

ret
urn

Group Sharing Policy 4

CP-ABE policy 2
CP-ABE policy 3
CP-ABE policy 4

Figure 10: Relationship between sharing policies and CP-ABE policies

The following piece of code shows an example of a high-level rule definition that defines a specificsharing policy considering the definition of bubbles and the use of CP-ABE policies. Specifically, theantecedent of the rule indicates a set of contextual conditions (e.g. location and time), while theconsequent specifies the CP-ABE policy which will be used under those contextual conditions. In thiscase, the CP-ABE policy is based on the attributes “bubbleA” and “friend”.
IFlocation=x AND time=y
THEN
CP-ABE policy=”bubbleA AND friend”

H2020 EUJ-02-2016

CPaaS.io

Page 24 of 48

Deliverable D5.2

User Empowerment Architectural

6 Interaction of components
6.1 Identity Management
The Privacy-Enhanced credential management system explained above can be used to authenticate users
and smart objects anonymously with a minimal attribute disclosure of private information. When asubject wants to access a IoT service, and both parties are endowed with the privacy preserving Identity
Management system, the user can provide the proof of credential following the Credential Proof
presentation process described in Section 4.1.2 as mean of authentication to gain access to the IoT
service. The following UML sequence diagram (Figure 11) describes this process using the different
security modules.

Figure 11: IoT Service Request with Privacy-Preserving Authentication

Firstly, a subject (user or smart object) acting as consumer, request some data from the IoT
service or virtual entity (producer);
Based on the IoT-A resolution infrastructure redirects the subject to the authentication module
letting know that the users wants to proof its identity using anonymous credentials (i.e.
cryptographic proof of possession of certain identity attributes);

H2020 EUJ-02-2016

CPaaS.io

Page 25 of 48

Deliverable D5.2















User Empowerment Architectural

The authentication module forwards the request to the claim verifier module of the Identity
Manager component of the framework which is in charge of verifying the subject proof of
credential;
The Identity Manager sends a random nonce value to the subject and waits for the credential
proof, which follows a credential specification. Optionally, depending on the implementation incase both sides support Presentation Policy mechanism, the Identity Manager sends the
Presentation Policy to the subject, which includes the particular identity attributes the subject has
to proof;
Depending on the actual context, the subject can select which credential (i.e. partial identity)
wants to use against the IoT Service, as long as, it also fulfils the minimum set of attributes(following the proof specification) required by the IoT Service;
The subject sends the credential proof (also called token) to the Token Claim verifier module ofthe Identity Manager of the IoT service. The identity Manager verifies the credential proof
following the particular Credential Engine cryptographic formulations. Notice that this could
optionally imply contact to a revocation authority and/or other additional entity in charge ofverifying signatures of certain attributes;
After a successful credential verification, the Identity Manager informs the Authentication
component which generates an authentication assertion to be used during the transaction an
optionally afterwards, depending on the validity time period of the assertion;
In the same process, the resolution infrastructure, before allowing the user gain access to the IoT
service data, asks the authorization component to make an authorization decision about the
subject accessing to the IoT service. This process is the same regardless of the kind ofauthentication performed previously. Although it is not shown here, to make the authorization
decision, the authorization module takes into account the context as well as trust and reputation
scores about the subject. (The authorization is explained in deep in Section 5);
The authorization module evaluates the access control policies and makes a decision that is sent
back to the resolution infrastructure of the framework which obtains the data from the IoT Service
and brings it to the subject.

6.2 Authorization request/response
The generic sequence diagram for controlling the access to IoT service using the context-based
authorization system is shown in Figure 12.

H2020 EUJ-02-2016

CPaaS.io

Page 26 of 48

Deliverable D5.2

User Empowerment Architectural

Figure 12: Authorization process












Firstly, a subject (user or smart object) acting as consumer, request some data the IoT service orvirtual entity (producer);
The architecture based on the IoT-A resolution infrastructure redirects the subject to theauthentication module to be authenticated. This process is explained in detail in Section 4 inwhich a privacy-preserving version of this process is provided;
After a successful authentication process, the Authentication component generates anauthentication assertion to be used during the transaction and optionally afterwards, dependingon the validity period of the assertion;
In the same process, the resolution infrastructure before let the user gain access to the IoT service
data, asks the Authorization component to make an authorization decision about that subject toaccess the IoT service;
To make the authorization decision, the Authorization component firstly obtains the contextual
information that is required in the authorization policies to make the decision. The type of
information to be considered will depend on the IoT Service being accessed and it will provided
by the Context Manager. Moreover, the Authorization component can request the trust andreputation scores about the smart object in order to avoid untrusted devices to gain access to the
IoT Service. Again, some contextual information can be needed to calculate trust scores for the
subject;
The Authorization component evaluates the access control policies and makes a decision that issent back to the resolution infrastructure of the framework which obtains the data from the IoT
Service and brings it to the subject.

6.3 Privacy/Security Group sharing
According to the previous framework definition and CP-ABE concepts, Figure 13 shows the sequence
diagram for the case of push-based data sharing. At high-level, three entities are considered for this
scenario:
H2020 EUJ-02-2016

CPaaS.io

Page 27 of 48

Deliverable D5.2





User Empowerment Architectural

The Subject role, acting as a consumer, which is intended to get access to a specific data;
The IoTService role, acting as a producer, which will be in charge of disseminating data in a secureway. Such entity consists of other modules of the proposed framework which will perform thetask of determining how the information will be disseminated;
Additionally, the attribute Authority role, responsible for generating CP-ABE keys for potential
consumers.

Figure 13: Secure Group Sharing

The description of the sequence diagram is as follows:Firstly, during an off-line phase, the subject wishes to get a CP-ABE key associated with a set of
attributes about their identity. These attributes can be specified in the form of an authentication
token or credential issued by a trusted entity. For this purpose, the subject presents it credentials
to the KEM module within the Attribute_Authority. Then, KEM verifies the credential andgenerates a CP-ABE key associated with the set of attributes that the consumer has shown in theprovided credential;
The data sharing is performed during an online phase.
oFirst, when the IoTService decides to disseminate (push) a certain data, it notifies theGroupManager module to perform this dissemination in a secure way for a set of potential
consumers. The GroupManager is the component responsible for encrypting data. The
decision on which CP-ABE policy to use for this data is determined by three factors:


H2020 EUJ-02-2016

The type of the data to be pushed (e.g. location, identity, etc.);
CPaaS.io

Page 28 of 48

Deliverable D5.2

User Empowerment Architectural

The current context of the IoTService which is obtained by requesting theContextManager module;

The values of trust and reputation associated with these policies which are
obtained by requesting the Trust & Reputation module.

oWhen these three values have been determined, sharing policies which are in the
sharingPolicies database of the GroupManager are evaluated. The result of this evaluation
will be a CP-ABE policy which will be used to encrypt the data;oFinally, a component CP-ABE Engine inside the Group Manager is responsible forencrypting the data with the policy obtained in the previous step;oOnce the data has been encrypted, it is returned to the IoTService actor which finally
pushes the encrypted data. Then, in case the CPABE_Key obtained in the offline phasesatisfies the CPABE_Policy used to encrypt, the subject can get accesses to data

H2020 EUJ-02-2016

CPaaS.io

Page 29 of 48

Deliverable D5.2

User Empowerment Architectural

7 Examples of Usage of the Privacy Preserving Technologies
7.1 Environmental monitoring
In this section, the environmental monitoring use case is presented. Environmental monitoring devices
are integrated into our CPaaS.io platform with the aim of providing reliable and secure access tomeasurements and services. Access to the environmental measurements and services is provided to
public transportation users as an additional service. One motivation for introducing environmental
monitoring data in public transportation applications is additional route optimization and planning. For
instance, low pollutant level and nice weather may be a motivation for travellers to use a bicycle as ameans of transportation.
Environmental pollution monitoring is regulated with appropriate institutions on various levels. The
European Commission defined air quality standards in [30]. In “Handbook on the Implementation of EC
Environmental Legislation” [32], section 5.4 “Data Collection and Reporting”, provides details regarding
data management requirements: “Data should be subject to quality control before they can be accepted
as part of an archive of data, which can then be used for the analysis of high pollution episodes or thedetection of trends in air quality over time. Where data need to be supplied rapidly (for example, to warn
the public regarding ozone levels) it may be impossible to complete all the quality assurance procedures.
Where this occurs, the data should be accompanied by a statement to this effect.”
Similar requirements may be found in the document “QA Handbook for Air Pollution Measurement
Systems Volume II [33]. In the section 5.3 “Environmental Data Operations”, attention is put on dataprotection: “Sample and/or measurement result handling - includes evidence that the sample and data
were protected from contamination and tampering during transfer between people and from the samplingsite to the laboratory and during analysis, transmittal, and storage. This process is documented in chain ofcustody forms”.
Environment monitoring is performed by appropriate government institutions in the respective countries.
In the USA it is the EPA (Environmental Protection Agency) and in the EU it is the EEA (European
Environment Agency).
In the environmental monitoring use case, devices equipped with various gas sensors periodically collectand upload environmental measurements to the server. On the server side, raw sensor measurements areprocessed in order to provide reliable measurements of various environmental measurements. Some ofthe server processing functionalities are: measurement calibration, outlier measurements rejection,
averaging, filtering, persistent storing, access to measurements, graphical data representation etc.
The key benefit of our CPaaS.io platform is the authentication and authorization processes. The
integration of the different components is illustrated in Figure 14.

H2020 EUJ-02-2016

CPaaS.io

Page 30 of 48

Deliverable D5.2

DeviceUser Empowerment Architectural

PEP_ProxyContext
BrokerAuthorization Request

Authorization Response
Registration

Capability
Manager

XACML

Authorization
RequestAuthorization
Response

ID
Management

User

ValidateRequestValidate
CT

RegistrationReg.
ResponseReg.
Response
Authorization Request

Authorization Response

Authorization
RequestAuthorization
Response

Validate
CT

ValidateRequestAuth request
ValidateRequestAuthorization Request
Authorization
RequestAuthorization
Response

Response

ValidateRequestQuery for resources/services
Validate
CT

Response
Get data
Figure 14: Environmental monitoring use case component interaction

Devices ask for authorization to register information into our CPaaS.io platform to the Capability
Manager authorization component. If the access is granted, it receives a CT. After the registration phase,the device must request authorization for data providing, once this access is granted, a new CT isgenerated. Using this CT, the device can incorporate their new information to our platform.
If a user intends to access the information, it should first be authenticated against our IdM component.
After that he must also follow the same authorization steps in order to receive a CT. With it, it will be able
to access the desired information.

H2020 EUJ-02-2016

CPaaS.io

Page 31 of 48

Deliverable D5.2

User Empowerment Architectural

7.2 Aggregated Traffic Data Visualization
This use case defines the process of publishing traffic data to the platform by different participants andthe process of sharing this data between different stakeholders using the security mechanisms
developed in the project. It involves the traffic data suppliers, which act as traffic data users
simultaneously, as well as users which only receive data from the platform. All data is provided by traffic
sensors and traffic signs that are part of real world traffic management installations.
The focus of the use case is on the traffic sensors and signs installed all over the motorways of one
country of example. These devices constantly send different kind of data to the operation centre. This ismainly traffic data like vehicle speeds but also status or error data. The data is aggregated on different
levels and published to the CPaaS.io Platform. The following aggregations & events are planned to be
published:

5, 15 and 60 minute based aggregation of vehicle speeds. In this aggregation the speeds ofsingle vehicles measured by a traffic sensor are aggregated on the stated levels;
5, 15 and 60 minute based aggregation of vehicle count. In this aggregation the number ofpassing vehicles measured by a traffic sensor are aggregated on the stated levels;
content change on traffic sign (event). This event is triggered if the content of a sign (or a groupof signs) is changed. This indicates special traffic situations like traffic jams;
error in traffic device group (event). This event is triggered if one device belonging to a groupof devices (e.g. on the same route) is in error state.

The traffic data aggregation and events are published to the platform by the Traffic Safe Wrapper (TSWrapper) to a corresponding topic. The TS Wrapper is a software component to represent several legacy
traffic devices to the platform.
The data can be visualized by a web application that subscribes to the topics and displays the data to thedifferent users. Every stakeholder involved in the use case is registered to the platform as a user. The web
application authorizes the data visualization for a certain user with the policy information from theplatform. Every user has access to the data he published to the platform and beyond that to the data ofother users if a corresponding policy exists. The web application provides functions to the users tomanage the access of other users to the own data. This way, users can decide very dynamically to grantor revoke data access to other users.
The accessible traffic data is shown in the web application but can also be processed directly, e.g. by the
TS Wrapper. The use case will deploy several TS Wrapper instances that use different users to publish
traffic data of different traffic installations. This demonstrates the capability to publish traffic data fromdifferent stakeholders to the platform and the protection of this data in the platform. One of this TS
Wrapper instances will control LED signs and subscribe to the content change event of other users. If theevent is triggered it will change the content of the own LED. This will demonstrate the possibility to use
status data of devices from one user as control input for another user.
The use case consists of several phases involving different components. In the following sequences weassume two users with different traffic hardware to be integrated into the platform and different
instances of the TS Wrapper.

H2020 EUJ-02-2016

CPaaS.io

Page 32 of 48

Deliverable D5.2

User Empowerment Architectural

Register Traffic Device in CPaaS.io platform
The TS Wrapper instance of a User is requesting the Capability Manager for a capability token to register
sensor/sign devices to the Context Broker. Depending on the user attributes, the Capability Manager asks
the XACML component to check the policies of the User (if he is allowed to register new devices to theContext Broker). If the operation is permitted the Capability Manager generates a token and sends it to
the TS Wrapper instance. The Capability token is used to register the device in the Context Broker (Figure15). The Context Broker finishes the registration process and sends the registration response to the TS
Wrapper instance. This step is repeated for every new device the TS Wrapper is going to register to theplatform.

Capability
ManagerContext
BrokerXACMLTSWrapper

TS Central

Traffic
Sensor/Sign

Request CapToken RD
getAuthZDecision
Evaluate
PolicyGenerate
CapToken

Data

Registration Request
(CT)

Data

Get Authfrom CT

RegisterContext
Register response

Figure 15: Traffic sensor/sign registration

H2020 EUJ-02-2016

CPaaS.io

Page 33 of 48

Deliverable D5.2

User Empowerment Architectural

Get Device List
If a user wants to access data from devices via the web application the first thing to do is to check which
devices are accessible to this user. After requesting a capability token to check if the user can request adevice list, the web application requests this list from the Context Broker (see Figure 16).

Web App
User A

Get
DeviceList

Capability
ManagerID
Management

PEP_ProxyContext
BrokerXACML

Request
CapTokenRD
getAttr
User
Attributes
getAuthZDecision
Evaluate
PolicyPermit/Deny
Generate
CapToken
CapToken CT
Request Device List (CT)

List of
Devices

List of Devices

ValidateCT
RequestDevice List
(CT)
List of
DevicesFigure 16: Request device list

H2020 EUJ-02-2016

CPaaS.io

Page 34 of 48

Deliverable D5.2

User Empowerment Architectural

Requesting data / Subscription
If the user requests data from a device or subscribes to its information via Context Broker (see Figure 17),a corresponding capability token is requested by the web application. The CT is used to get therequested data. In case of a subscription the published data from the device will be directly notified to
the web application and shown to the user. The data is encrypted with CP-ABE. To decrypt the messages
the web application uses its CP-ABE Key.

Web App

Context
Broker

PEP_Proxy

User A

Request/Subscribe Topic

Capability
ManagerID
Management

Request Auth

XACML

TS
WrapperA

TS
CentralTraffic
Sensor/Sign

ValidateRequestAuth Token
Authorization Request

Authorization Request

Authorization Response

Authorization
Response

ValidateRequestValidateRequest

Data

Subs.
Request

Subs
Reply

Encr.
CPABE

Request CapToken
CapToken

PublishNotifyDecr. CPABE
Figure 17: Requesting / subscribing to traffic data

H2020 EUJ-02-2016

CPaaS.io

Page 35 of 48

Deliverable D5.2

User Empowerment Architectural

8 IoT Service Integration through eTRON Architecture and Omotenashi
PlatformeTRON is a pervasive security architecture that advocates using tamper-resistant hardware for storing
personal information. Using such hardware, typically in the form of an IC card, users can seamlessly gain
access to multiple services through the Omotenashi cloud platform. It should, however, be noted that the
Omotenashi platform (see Figure 18 below) is not limited to the use of eTRON cards, any IC cards
compliant with GlobalPlatform card speciation can plug into it. We explain the eTRON architecture andOmotenashi platform in the following two sub-sections.

Figure 18: eTRON and Omotenashi Platform in the overarching u2 Architecture

8.1 eTRON
Entity TRON (or eTRON) is a pervasive security concept that has grown out of the TRON project [23]. The
idea is to protect “electronic entities” that represent some kind of value (it could be encryption keys orconcert tickets or commuter passes, etc.) by storing them inside a tamper resistant piece of hardware.
This tamper-resistant hardware is the eTRON chip. The eTRON chips come in a number of generations,and are certified by the Japanese Ubiquitous ID Center [24] which is a subproject of TRON Forum [25].
The eTRON chips are not simply security co-processors as commonly used, but actually complete
systems containing both processing power and memory for code and data. Though eTRON was initiallyintended as security support for TRON-based systems, it has eventually evolved – with research spanningover a decade – as a comprehensive architecture for building secure and efficient e-services [29].

H2020 EUJ-02-2016

CPaaS.io

Page 36 of 48

Deliverable D5.2

User Empowerment Architectural

8.1.1 The eTRON Architecture
eTRON is a basic architecture for “electronic entity” management. The term “electronic entity” or simply“entity”, in eTRON parlance, represents special digital information that resembles real-life objects likecertificates, banknotes or keys. Certificates or banknotes are difficult to duplicate or alter as they use
special papers, special ink, water marks or holograms. Keys are difficult to produce or reproduce as they
have precisely cut edges made form hard materials. The “electronic entity”, as envisioned in the eTRON
architecture, should have such properties that make them difficult to produce, duplicate and alter.
Creating an electronic entity is impossible with software alone, and hardware support is indispensable.
The eTRON tamper-resistant hardware device can provide such support. Figure 19 shows the basic
hardware module of eTRON, and Figure 20 shows two different types of eTRON devices. An electronic
entity produced by eTRON tamper-resistant hardware is composed of an indivisible unit of data. Such an
electronic entity is difficult to counterfeit, produce a pirated copy, and illegally modify.
Manipulation of electronic entities inside eTRON hardware is strictly governed by the entity Transfer
Protocol (eTP) which features only a limited set of operations that can be exerted only after stringent
mutual authentication and access control requirements have been satisfied [26].

Figure 19: eTRON Hardware Module

Figure 20: eTRON chips: SIM-type (left) and USB-type (right)

H2020 EUJ-02-2016

CPaaS.io

Page 37 of 48

Deliverable D5.2

User Empowerment Architectural

8.1.2 Mutual Authentication
The eTRON mutual authentication is performed by a challenge-response protocol using public key
cryptography. After successful authentication, a session is created to share a secure key by Diffie-Hellman
algorithm. By this session establishment an ephemeral key, valid only for the duration of the session, isshared between the interlocutors (in our case, the user and the authentication system at the enterprise inquestion) by Diffie-Hellman key sharing algorithm.
In the eTRON architecture, this session is established in two phases (see Figure 21); first a shared key isgenerated, and then the key is verified. For explaining the session establishment process, we assume thata session is established between A and B. For Diffie-Hellman key sharing, A and B have their respective
secret and public keys, and certificates, which are denoted by x, y and cert respectively, differentiated by
A or B in the subscript. There are also two Diffie-Hellman protocol system parameters which are publicly
known: p and g, where p is a prime number and g is an integer less than p, with the following property:
for every number n between 1 and p-1 inclusive, there is a power k of g such that n = gk mod p. x and y
are related as y = gx mod p. The protocol is specified below.

Figure 21: eTRON Session Establishment Protocol

Key Generation
 A generates a random number, RA and calculates a commit value, rA  g R mod p and sends (rA , cert A ) to B.
 B receives (rA , cert A ) from A. B verifies the validity of cert A . B generates a random number RB, and calculates acommit value, rB  g R mod p . B sends (rB , cert B ) to A. B calculates K   (rA x )  ( yA R ) mod p .
 A verifies B’s certificate, cert B and then calculates K  (rB x )  ( yB R ) mod p.
A

B

B

A

B

A

Key Confirmation
 A extracts the first 128 bits of K (which is represented in little-endian) as w0  f128( K ). A then calculates
VA  h(w0 | cert B | rB ), known as authorization child, where h(.) represents SHA-1 hash function. Then A
calculates cA  Ew (VA ), where Ew (.) represents symmetric key encryption with key w0 . c A is sent to B.
 B receives c A . It extracts the first 128 bits of K  (which is represented in little-endian) as w0  f128( K ). B thencalculates VA  h(w0 | cert B | rB ) as authorization child, and V~A  Dw (cA ), where Dw (.) is the decryption of theoperand with key w0 . If V A and V~A are same, then K  is registered as the session key. Next, B calculates its000

H2020 EUJ-02-2016

CPaaS.io0Page 38 of 48

Deliverable D5.2

User Empowerment Architectural

authorization child, VB  h(w0 | cert A | rA ) and cB  Ew (VB ), where Ew (.) represents symmetric key encryption
with key w0 . cB is sent to A.
A receives cB . A calculates authorization child, VB  h(w0 | cert A | rA ) and V~B  Dw (cB ), where Dw (.) is the
0



0

0

0

decryption of the operand with key w0 . If V B and V~B are same, then K is registered as the session key. Thisway, a shared key K ( K ) is agreed between A and B.

8.1.3 File Access Control
In the eTRON architecture, mutual authentication has two modes: owner mode and issuer mode. By“owner” we mean owner of the chip or electronic entity and by “issuer” we mean issuer or creator of theentity (e.g., eTRON files or records). When an eTRON file is created, the eTRON ID of the issuer is
attached to the file’s file control block.
Issuer mode authentication is granted only when request to access an entity (file) comes from a party
having the same eTRON ID as is written in the file control block of the entity. If the eTRON IDs match, therequesting party is given “issuer authority”. Otherwise, “other authority” is given. On the other hand, inowner mode authentication, the requesting party proves himself as the owner of the chip by password or
PIN, and upon successful authentication “owner authority” is granted.
Table 1. File access control list in eTRON.

eTRON’s access control mechanism is based on access control lists. As shown in Table 1, the file access
control list in eTRON is defined by setting or resetting different bits of a 16-bit value. “Issuer” of entity(file) has all rights by default, and rights for “owner” and “others” can be set for eight access privileges,
namely updating record, reading record, changing mode of a file, acquiring status of a file, deleting file,transferring file, encrypting file, and decrypting file. The file access control list is defined by the issuer ofthe file during the file creation process. In comparison to the commonly followed state-based or rulebased access control techniques in smartcards [27], eTRON’s access control mechanism offers several
advantages:Firstly, it is straight-forward and explicit, and suitable for many applications;
It has eight well defined access privileges and three different levels of access authorities. In
contrast, state-based access control can be at times prohibitively complex with increasing numberof states;
Access definition of each file is part of the file control block, which is unlike the rule-based access
control where compromise of the special reference file may lead to the compromise of all otherfiles.

The eTRON access control mechanism can work in flat file structure also, whereas state-based and rulebased access controls often rely on directory hierarchy to define states and rules respectively.

H2020 EUJ-02-2016

CPaaS.io

Page 39 of 48

Deliverable D5.2

User Empowerment Architectural

Moreover, eTRON’s access control mechanism allows programming multiple applications in a single chipvery easily, just by defining different access rights to different files pertaining to different applications.

8.1.4 Secure Peer-to-Peer Communication
Each eTRON chip is assigned a unique identifier (eTRON ID), to create a persistent and reliable
identification of each eTRON chip, regardless of communications channels and other variable factors.
This is a key part of the end-to-end architecture, as it is used to ascertain the identity of the counterpart
in a transaction. eTRON uses Public Key Infrastructure (PKI) where a certificate authority issues certificatesto chips having valid eTRON IDs. The eTRON architecture calls for eTRON chips to connect directly toeach other over any available communications infrastructure, forming virtual, encrypted, and private endto-end connections for the transfer of entities over the eTNet architecture [28].

8.1.5 eTRON Libraries
The eTRON access library, which mainly consists of eTRON client library and eTRON utility library,provides API commands for accessing eTRON chips and manipulating entities inside those. These
libraries are compatible with C and C++, and can be used for application development in T-Kernel, Unix
OS, MacOSX, and Windows.
eTRON Client Library. The eTRON client library provides functions for communicating with eTRON chips
via the utility library. The client library can be divided into the following seven major modules (Figure 22).
 Entity module: Applications and middleware basically use the entity module which provides API for
issuing commands to eTRON entities for different applications. It also includes functions forconnecting with the packet module, adapter module, authentication module, crypto module, and
MAC/HASH module; Packet module: This provides protocol processing functions according to eTRON specifications suchas eTRON/16 and eTRON/32. eTRON/16 chip has a 16-bit micro-controller, and eTRON/32 chip has
a 32-bit microcontroller; Device module: A variety of interfacing devices and reader/writers can be used to interface eTRON
chips to computers. Examples include PC/SC (personal computer/smartcard) compliant
reader/writer, DENSO reader/writer, T-Engine SIM adapter, etc. Device module provides functions
to treat streams defined by these interfacing devices, reader/writers, and also by the utility library; Authentication module: This module provides necessary parameter creation functions for the twopass authentication according to eTRON specifications; Crypto module: This module provides encryption communication functions that are used between
eTRON chips and computers. This can also be used as a stand-alone crypto library; MAC/HASH module: This module provides functions to compute MAC/HASH values to be
appended to eTRON packets for packet transfer error- and alteration-detection, and message
authentication;
 Utility module: This module provides auxiliary functions for using eTRON client library, such as error
handling, time processing, and key management.
 eTRON Utility Library: The utility library mainly provides multi-platform support functions including
string and task/thread handling, socket and time control, inter-process communication, etc.; andother basic functions like message list and buffer handling, debugging support and error handling,etc. These client library and utility library provide various API commands for interacting with andmanipulating entities.
H2020 EUJ-02-2016

CPaaS.io

Page 40 of 48

Deliverable D5.2

User Empowerment Architectural

Figure 22: Configuration of Modules in eTRON Client Library

8.2 Omotenashi Platform
8.2.1 Architecture
The TRON Project has been aiming at realizing the vision of IoT in which many computers in oursurroundings cooperate together to offer better services to improve the quality of everyday living. To
realize such an environment, we need the mechanism to let objects to communicate with each other forthe sake of collaboration. But we also need a mechanism to learn and collect user contexts such as thelanguage spoken, age, many physical characteristics, preferences, etc. Such knowledge must be reflected
to create an optimized environment. For this purpose, the TRON Project is now building a generalpurpose Personal Data Store (PDS) using IoT and cloud computing technology. We call this PDS“Omotenashi Cloud”, as depicted in Figure 18 where multiple services are aggregated on a single
platform which can be accessed by a single eTRON card or smarphone. Omotenashi is a Japanese wordthat encapsulates a multitude of hospitality philosophy and practices rooted in Japanese culture.

H2020 EUJ-02-2016

CPaaS.io

Page 41 of 48

Deliverable D5.2

User Empowerment Architectural

Figure 23: The omotenashi cloud aggregates a variety of services on a single platform

In the short time span, this “Omotenashi cloud” (Figure 23) can be used to advance the hospitality service
to the increasing number of overseas tourists who are expected to peak during 2020 Tokyo Olympics
and Paralympics. Customers (consumers) store their individual characteristics such as preferred spoken
language, food preferences, passport information for sales tax-exemption in the cloud. From theapplication dashboard, users can select in advance what information to share with which vendors, andcan thus control access to their information based context attributes and trust levels. Once the data isstored, such information is easily retrieved and passed on the spot to service providers such as storesand public services by using the smartphone apps or transportation IC cards as retrieval key.
The party who receives a service escrows the personal data in the PDS cloud, and lets it pass the data to
the service vendors as the need arises. So, it is the customer (consumer) that controls the vendors. This
concept, Vendor Relationship Management (VRM) is the reverse of the conventional idea of Customer
Relationship Management (CRM).
The Omotenashi Cloud plays the important role of PDS in the scheme. This framework has been
designed to be useful as legacy service platform in Japan even after 2020 when it will be utilized verymuch for hospitality service to foreign tourists. Small regional service vendors who did not have theresources to build conventional CRM can join Omotenashi Cloud service framework and can now provide
better services suited for the new IoT age. Omotenashi Cloud will be useful for invigorating regional
economy and is also expected to add to e-inclusion by accelerating the realization of Enableware andassistive technologies.
To summarize, the Omotenashi Platform realizes open collaboration of service industries by sharing
customer attribute data across service providers (Figure 24). Only the information licensed by the user isprovided to the service providers. In other words, users control which information to share with which
service providers in a fine-grained manner.

H2020 EUJ-02-2016

CPaaS.io

Page 42 of 48

Deliverable D5.2

User Empowerment Architectural

Figure 24: Architectural Overview of the Omotenashi Cloud Platform

Figure 25: Use Case Examples of Omotenashi Cloud Platform

8.2.2 Use Cases
We present hereafter some simple use cases (see Figure 25):

H2020 EUJ-02-2016

CPaaS.io

Page 43 of 48

Deliverable D5.2

User Empowerment Architecturala) Seamless Information Sharing: If the user adjusts the size of the clothes at apparel shop A, andregisters it on the Omotenashi infrastructure, another shop B can also use the registeredinformation to sell the clothes.
b) Context-aware Navigation Information: Route guide will be shown on display, if a user places her
card on a signage terminal. The system will guide a user to destination based on user information
registered in the card. For example, for persons using wheelchairs, routes with no stairs or bumps
are displayed. For persons with visual impairment, route with Braille tiles will be announced inaudio.
c) Emergency Support for Foreign Tourists: By placing card onto the battery-powered disaster
Information signage terminals, safety information can be notified.

H2020 EUJ-02-2016

CPaaS.io

Page 44 of 48

Deliverable D5.2

9

User Empowerment Architectural

Conclusions

According to Task 5.1 and Task 5.2, in this deliverable we have defined the main components for user
empowerment providing a more pragmatic and functional view. In addition, we have also provided a new
privacy preserving mechanism based on Ciphertext-Policy Attribute-Based Encryption.
Along this document, such a pragmatic view can be noted on the different security properties being
handled by our CPaaS.io platform such as authentication, authorization, identity management and theprevious privacy mechanism with the purpose of securing information broadcast over a shared media toa group of consumers. Moreover, IoT service integration through eTRON architecture and Omotenashi
platform, and user-centric access thereof has been presented.
In addition, the interactions between these security components have been presented in order to provide
a better and clearer understanding of how our CPaaS.io components work together. With the same
purpose, we have also incorporated in this document diverse use cases providing different examples of
our CPaaS.io platform applications.

H2020 EUJ-02-2016

CPaaS.io

Page 45 of 48

Deliverable D5.2

User Empowerment Architectural

10 References[1] A. Skarmerta. CPaaS.io Deliverable 5.1. Empowerment Components Definition V1.0, March 2016.
[2] SAML (Security Assertion Markup Language): http://docs.oasis-open.org/security/saml/v2.0[3] OASIS Standard. eXtensible Access Control Markup Language (XACML) Version 3.0. January 2013:
http://docs.oasis-open.org/xacml/3.0[4] J. L. Hernández-Ramos, A. J. Jara, L. Marín, and A. F. Skarmeta, “Dcapbac: Embedding authorization
logic into smart things through ecc optimizations,” International Journal of Computer Mathematics,
no. just-accepted, pp. 1–22, 2014.
[5] D. Boneh and M. Franklin, “Identity-based encryption from the weil pairing,” in Advances in
Cryptology—CRYPTO 2001. Springer, 2001, pp. 213–229[6] A. Sahai and B. Waters, “Fuzzy identity-based encryption,” in Advances in Cryptology–EUROCRYPT
2005. Springer, 2005, pp. 457–473[7] J. Bethencourt, A. Sahai, and B. Waters, “Ciphertext-policy attribute-based encryption,” in Security
and Privacy, 2007. SP’07. IEEE Symposium on. IEEE, 2007, pp. 321–334.
[8] Specification of the Identity Mixer Cryptographic Library. Version 2.3.40 IBM Research, Zurich January
30, 2013. Available http://www.zurich.ibm.com/idemix/[9] U-Prove Cryptographic Specification V1.1. Revision 3. Microsoft Corporation Authors: Christian
Paquin, Greg Zaverucha, December 2013. Available at http://research.microsoft.com/enus/projects/u-prove/[10] Heer, T., Garcia-Morchon, O., Hummen, R., Keoh, S. L., Kumar, S. S., & Wehrle, K. (2011). Security
Challenges in the IP-based Internet of Things. Wireless Personal Communications, 61(3), 527-542[11] Gusmeroli, S., Piccione, S., &Rotondi, D. (2013). A capability-based security approach to manage
access control in the internet of things. Mathematical and Computer Modelling, 58(5), 1189-1205.
[12] Hernández-Ramos, J. L., Jara, A. J., Marın, L., &Skarmeta, A. F. (2013). Distributed capability-based
access control for the internet of things. Journal of Internet Services and Information Security (JISIS),
3(3/4), 1-16.
[13] Sakimura, N. (2015). JSON Web Token (JWT) (No. RFC 7519).
[14] Li, S., Hoebeke, J., Van den Abeele, F., & Jara, A. (2012). Conditional observe in CoAP. Constrained
Resources (CoRE) Working Group, Internet Engineering Task Force (IETF), work in progress, draft-licore-conditional-observe-03.
H2020 EUJ-02-2016

CPaaS.io

Page 46 of 48

Deliverable D5.2

User Empowerment Architectural[15] N. Hardy. “The Confused Deputy:(or why capabilities might have been invented)”. ACM SIGOPS
Operating Systems Review, 22(4), 36-38. 1988.
[16] Theapplication/jsonMedia
https://tools.ietf.org/html/rfc4627

Type

for

JavaScript

ObjectNotation(JSON)-[17] Griffin, L., Butler, B., de Leastar, E., Jennings, B., & Botvich, D. (2012, July). On the performance ofaccess control policy evaluation. In Policies for Distributed Systems and Networks (POLICY), 2012 IEEE
International Symposium on (pp. 25-32). IEEE
[18] Ferraiolo, D., Cugini, J., & Kuhn, D. R. (1995, December). Role-based access control (RBAC): Featuresand motivations. In Proceedings of 11th annual computer security application conference (pp. 24148).
[19] Yuan, E., & Tong, J. (2005, July). Attributed based access control (ABAC) for web services. In Web
Services, 2005. ICWS 2005. Proceedings. 2005 IEEE International Conference on. IEEE.
[20] Gusmeroli, S., Piccione, S., &Rotondi, D. (2013). A capability-based security approach to manage
access control in the internet of things. Mathematical and Computer Modelling, 58(5), 1189-1205.
[21] The Constrained Application Protocol (CoAP) - https://tools.ietf.org/html/rfc7252[22] Hernández-Ramos, J. L., Jara, A. J., Marın, L., &Skarmeta, A. F. (2013). Distributed capability-based
access control for the internet of things. Journal of Internet Services and Information Security (JISIS),
3(3/4), 1-16.
[23] J. Krikke, “T-Engine: Japan’s ubiquitous computing architecture is ready for prime time,” IEEE
Pervasive Computing, Vol. 4, No. 2, April 2005, pp. 4-9.
[24] K. Sakamura and N. Koshizuka “Ubiquitous ID: Standards for Ubiquitous Computing and the Internetof Things,” IEEE Pervasive Computing. 9(4), 2010, pp. 98-101.
[25] K. Sakamura and N. Koshizuka, “The eTRON wide-area distributed-system architecture for ecommerce,” IEEE Micro, Vol. 21, No. 6, 2001, pp. 7-12.
[26] TRON FORUM. (2017) [Online] Available from: http://www.tron.org/[27] W. Rankl, “Smart Card Applications: Design Models for Using and Programming Smart Cards”. 3rd
Ed. West Sussex: John Wiley & Sons Ltd., 2007.
[28] T. Yashiro, M. F. F. Khan, S. Ito, M. Bessho, S. Kobayashi, T. Usaka, N. Koshizuka and K. Sakamura,“eTNet: A smart card network architecture for flexible electronic commerce services,” 4th IFIP Int’lConference on New Technologies, Mobility and Security, 2011, pp. 1-5.
[29] M.F.F. Khan, K. Sakamura, N. Koshizuka, “Robust Enterprise Application Security with eTRON
Architecture.” In: Chang V., Ramachandran M., Walters R., Wills G. (eds) Enterprise Security. Lecture
Notes in Computer Science, vol 10131. Springer, 2017, pp. 155-178.
H2020 EUJ-02-2016

CPaaS.io

Page 47 of 48

Deliverable D5.2

User Empowerment Architectural[30] EC, Environment, Air Quality Standards, http://ec.europa.eu/environment/air/quality/standards.htm[31] Quality Assurance Handbook for Air Pollution Measurement Systems document,
http://www3.epa.gov/ttnamti1/files/ambient/pm25/qa/QA-Handbook-Vol-II.pdf[32] Handbook on the Implementation of EC Environmental Legislation,
http://ec.europa.eu/environment/archives/air/pdf/air.pdf[33] QA Handbook for Air Pollution Measurement Systems Volume II,
http://www3.epa.gov/ttnamti1/files/ambient/pm25/qa/QA-Handbook-Vol-II.pdf[34] Environmental Protection Agency - Ministry of Agriculture and Environmental Protection,
http://www.sepa.gov.rs/

H2020 EUJ-02-2016

CPaaS.io

Page 48 of 48