deliverable d3.3 context-sensitive security,...

DELIVERABLE

ThisprojecthasreceivedfinancialsupportfromtheEuropeanUnionHorizon2020Programmeundergrantagreementno.688203.

D3.3Context-SensitiveSecurity,PrivacyManagement,AdaptationFrameworkv1

ProjectAcronym: bIoTopeProjecttitle: BuildinganIoTOpenInnovationEcosystemforConnectedSmartObjectsGrantAgreementNo. 688203Website: www.bIoTope-project.orgVersion: 1.0Date: 31March2017ResponsiblePartner: ULContributingPartners: UL,AaltoDisseminationLevel: Public X

Confidential–onlyconsortiummembersandEuropeanCommissionServices

Ref. Ares(2017)1979548 - 17/04/2017

D3.3Context-SensitiveSecurity,PrivacyManagement,AdaptationFramework

©688203bIoTopeProjectPartners 2 31-March-17

RevisionHistory

Revision Date Author Organization Description

0.1 03/01/2017 JérémyROBERT UL Initialdraft

0.2 24/02/2017 SylvainKubler UL Revision24Feb.2017

0.3 28/02/2017 JérémyROBERT UL Consolidatedversion

0.4 08/03/2017 JérémyROBERT UL IntegrationoftheHolonix’scomments(SimoneParrotta)

0.5 16/03/2017 JérémyROBERT UL IntegrationofIS-Pratice’scomments(HugoKerschot)

0.6 20/03/2017 JérémyROBERT UL IntegrationofItrust’scomments(JeanLancrenon/SankalpGhatpande)

1.0 23/03/2017 JérémyROBERT UL Preparationoffinalversion



TableofContents

1. Introduction...........................................................................................................................7

2. O-MIreferenceimplementation.............................................................................................92.1. Reminderonthecurrentreferenceimplementation....................................................................92.2. Discussionaboutthesecurityinthereferenceimplementation.................................................13

3. SecuritymodulesfortheO-MInode.....................................................................................143.1. Accesscontrolandauthenticationmechanismfortheend-usersoftheO-MIwebclient.............143.2. SecureO-MI/O-DFinformationexchangeforthirdpartyapplications........................................17

4. Security&PrivacywiththeservicecatalogueIoTBnB...........................................................194.1. SecuritymanagementwithIoTBnB.............................................................................................194.2. PrivacymanagementstrategieswithIoTBnB..............................................................................24

5. Conclusion............................................................................................................................27

6. References...........................................................................................................................28



ListofTables

Table2-1MainMessagingInterfacesspecifiedintheO-MIstandards............................................................10Table3-1Parametersforaskingthetoken.......................................................................................................17

ListofFigures

Figure1-1bIoTopearchitecturalframework......................................................................................................8Figure2-1O-MIreferenceimplementation........................................................................................................9Figure2-2IllustrationoftheO-DFstructure.....................................................................................................10Figure2-3WebpageoftheO-MIwebclient(hereforthenode’sURLhttp://biotope.sntiotlab.lu:8080)........10Figure2-4DiscoveringoftheObjectNetatmointheObject(s)SnTandIoTlab...............................................11Figure 2-5 O-MI webclient UI after clicking ‘Read All’ (with the published O-DF tree), and selecting the

InfoItemTemperatureIndoorintheObject(s)SnT,IoTlabandNetatmo..................................................12Figure2-6OverviewofthemodulesdevelopedinthisdeliverableD3.3ontheglobalpictureofthebIoTope

project.......................................................................................................................................................13Figure3-1Databaseschemaofthesecuritymodule........................................................................................15Figure 3-2 Scenario for authenticating the user ‘Administrator’ and giving access to the permission

managementinterface............................................................................................................................15Figure3-3ScenarioforauthenticatingauserandgivingaccesstotheO-DFresource....................................16Figure3-4Accessmanagementinterface.........................................................................................................16Figure3-5Scenarioforgivingaccesstoathird-partyapplication....................................................................17Figure 4-1 Seller scenario for publishing/selling his/her own IoT data/service thanks to the IoTBnB

marketplace...............................................................................................................................................19Figure4-2Userauthenticationphasefromtheauthentication-as-a-servicecomponent,i.eAuth0...............20Figure4-3UserProfileintheservicecatalogue................................................................................................20Figure4-4O-MIserverinformationfromasellerperspectiveintheservicecatalogue...................................21Figure4-5SellerpublisheddataintheIoTBnBwebsite....................................................................................21Figure4-6Buyerscenarioforsearchingfor/buyingdata/serviceintheIoTBnBwebsite.................................21Figure4-7Exampleofsearchingbasedonthekeyword‘moisture’.................................................................23Figure4-8Exampleofthebuyercart................................................................................................................23Figure4-9Paymentstep(notimplementedyet)..............................................................................................23Figure4-10Buyerdashboardwiththepurchaseddata/serviceandrelatedtoken..........................................24Figure 4-11 Buyer scenario for searching for/buying data/service in the IoTBnB website with username

anonymization...........................................................................................................................................24Figure4-12Pseudonymizationidea..................................................................................................................25Figure4-13k-anonymizationidea.....................................................................................................................26



AcronymsandDefinitions

Acronym DefinitionACL AccessControlListAPI ApplicationProgrammingInterfacebIoTope BuildinganIoTOpeninnovationEcosystemforconnectedsmartobjectsHTML HyperTextMarkupLanguageHTTP HyperTextTransferProtocolIoT InternetofThingsIoTBnB IoTservicepuBlicationaNdBillingIT InformationTechnologyJS JavaScriptJSON JavaScriptObjectNotationJVM JavaVirtualMachineO-DF OpenDataFormatO-MI OpenMessagingInterfacePII PersonalIdentifiableInformationREST RepresentationalStateTransferRO ReadOnlyRW ReadWriteSLA ServiceLevelAgreementTCP/IP TransmissionControlProtocol/InternetProtocol(ProtocolStack)UI UserInterfaceUL UniversityofLuxembourgURL UniformResourceLocatorWP WorkPackageXML eXtensibleMarkupLanguage



ExecutiveSummary

This deliverable is part of the scope ofWP3 (Building a Secure, Open & Standardised Systems ofSystemsPlatformforIoT),whichprovidesthetechnologicalfoundationofthebIoTopeSystemsofSystems(SoS)PlatformforinformationsourcepublicationandconsumptionintheIoT,basedontheO-MIandO-DFstandards.This includesnewmechanismstobettermanage‘Identities’and‘Context-sensitiveSecurityandPrivacy’(SaaS)ofConnectedSmartObjectsandPeopletocopewiththedynamicnatureoftheIoT.

Security,privacyandtrustarestillcriticalissuesintoday’sIoT.Eventhoughthereisnorealconsensuson how to implement security in the IoT, it is very important to define valid security, privacy and trustmodelsthatcopewithIoTpeculiaritiestoreachafullacceptancebytheend-users.Inthatsense,theaimofthisdeliverableistostartwiththetechnologicalbuildingblocksthatenable:

• end-userstoaccesstheO-MI/O-DFreferenceimplementationinasecureway,• third-partyapplicationstoeasilyaccesstheO-DFresourcespublishedbytheO-MI/O-DFreference

implementationandtohaveafullauthoritytogranttheaccesstotheirend-users• a first level of end-user privacy management through the bIoTope service catalogue (named

IoTBnB)

AsthedeliverableD3.1manage‘Identities’byusingtrust-basednetworks,thisisthefirstdeliverabledealingwithsecurityandprivacyissues,whichisintendedtobemoreatechnicalreportofthedevelopedsolutionsthanastate-of-the-artofthesecuritysolutions. Thefollowingdeliverable,scheduledatmonth29(31stofMay 2018), will focus on more complex scenarios in the future; i.e., when interacting with WP4 where‘Contexts’ relates to human beings or physical objects will be taken into consideration (e.g., location,situation,leveloftrustorreputationofthesurroundingentitiesandobjects,etc...).



1. Introduction

Today,connecteddevicesare increasinglypresentand interconnected inoureveryday lives (e.g.,weatherstations,lights,babymonitors,cars,TVs,smartwatches,smartshoes,bikestations,etc.).ThesedevicesareconnectedtotheInternetthroughheterogeneoustechnologies,fosteringthecreationofinnovativeservicesin various domains including smart home, healthcare, energy, transportation, and so forth. However,security,privacyandtrustarestillcriticalissuesintoday’sIoT.Forexample,thesecurityfirmKasperskyeventalkedabout ‘InternetofCrappyThings’ [1],explaininghowahacker couldwashhis car freeof chargeorstalk someone by exploiting security breaches of a connected carwash or a connected fitness tracker.Anotherexampleistheexposureofthemostprivatemomentsthroughbabymonitors,asassessedbythesecurity firm Rapid 71[2]. The crux of the issue is that today’s security, privacy and trust models are‘Organization-centric’ratherthan‘Humancentric’,leadingtotransparencyandauditabilityissues,especiallyin Cloud-based environments. Indeed, even in the presence of Service Level Agreements (SLAs), currentplatform owners have very few incentives to develop platform privacy since the relationships with theconsumeraremostlygovernedbyunilateralcontracts(i.e.providerdefined).Thewhitepaperpublishedbythe security firmWind River2confirms this statement, inwhich the authors claim that the security is thefoundationalenablerofIoTbutthereisnorealconsensusonhowtoimplementsecurityintheIoT[3].Itisofthe utmost importance to define soon, valid security, privacy and trust models that cope with IoTpeculiaritiestoreachafullacceptancebytheend-users[4].Intheliterature,threemajorresearchtracksarepresented[5]:

• ‘Whistleblower’papersthatpointoutsecurityandprivacyissuesintheIoT(asforexamplethewhitepapersorcritiquesabove-cited),

• Technicalpapersthatoffersecurityprovisions,• Legalpapersthatdevelopframeworkaboutsecurity-privacyregulationsandlawsintheIoT[6-

7].

Common to all of the above research is theneeds toanswer the followingquestions:how toprotectdataexchangesbetweenvariousinformationsystems?howtomanageauthenticationandaccesscontrolinaworldofbillionsofthings?whatabouttheprivacyofend-users,andthesecurityofthedatageneratedbythings?[8].Vasilomanolakis&al.defineataxonomyoftheseIoTsecuritychallenges,basedonfivedifferentgroups(andtheirsubcomponents)[9],namely:

• NetworkSecurity:Confidentiality,Integrity,AuthenticityandAvailability• IdentityManagement:Authentication,Authorization,AccountabilityandRevocation• Privacy:DataPrivacy,Anonymity,Pseudonimity,Unlinkability• Trust:Devicetrust,Entitytrustanddatatrust• Resilience:RobustnessagainstattacksandResilienceagainstfailures

Although most of the examples given above show security breaches at the device level, security

considerationsareorthogonaltotheotherresearchareas[10],andspanallthelevelsoftheIoTarchitecturalframeworkasdepicted inFigure1-1, i.e.atthenetwork level (localor Internetcommunications),gatewaylevelaswellasattheapplicationlevel.Figure1-1depictsthegenericIoTarchitecturalframeworkthathasbeen instantiated to the bIoTope project. It shows the enabler components to achieve interoperabilitybetween vertical silos based on the O-MI/O-DF standards at the gateway level (i.e., considering O-MInodes/serversattheedgenetwork).

1https://www.rapid7.com/2https://www.windriver.com/



Figure1-1bIoTopearchitecturalframework

Asmarked in Figure 1-1 this deliverablemainly focuses on security at the gateway level (i.e., at thebIoTope edge nodes that correspond to the O-MI servers/gateways), and will constitute our studyperimeter.Thisdeliverable ismoreatechnicalreportofthedevelopedsolutionsthanastate-of-the-artofthesecuritysolutions.Theobjectiveistolaythebuildingblockforthedefinitionofmorecomplexscenariosinthefuture;i.e.,wheninteractingwithWP4where‘Contexts’relatedtohumanbeingsorphysicalobjectswill be taken into consideration (e.g., location, situation, level of trust or reputation of the surroundingentitiesandobjects...).

Chapter2presents thecurrentO-MI/O-DFreference implementation fromaconceptualandtechnical

viewpoint.Adiscussionabout thesecurityaspects isalsoprovidedto introducethenewsecuritymodulesdevelopedinthisdeliverable.

Chapter 3 presents the two independent security modules that are developed to enable end-users

and/orthird-partyapplicationstoaccesstotheresources(O-DFpayload)availablethroughtheO-MInode.First, authentication of the end-users is made available ‘as-a-service’ with the use of the external webservice Auth0. Second, the authentication of the third-party applications is based on the JWT (JsonWebToken)tokentechnology.

Chapter4detailshowanIoTdata/serviceprovidercanexposehis/herowndata/servicestotheservice

catalogue (developed in the bIoTope project)while benefiting from the securitymodule and how an IoTdata/service consumer can use the service that he/she has purchased from the service catalogue. Inaddition,afirstlevelofprivacyisimplementedandreliesontheend-usersanonymizationtechniques.



2. O-MIreferenceimplementation

2.1. Reminderonthecurrentreferenceimplementation

bIoTopeconsortiumstronglybelievesthattheadoptionofanystandardrequireseasy-to-useandeasy-to-implementsolutionstotryanduseit(i.e.,avoidinghavingonlywrittenstandardsspecifications). Inthisrespect,theO-MIandO-DFstandardswereturnedintoanopenreferenceimplementation(availableonline:https://github.com/AaltoAsia/O-MI), the development activities of which are coordinated by AaltoUniversity. Downloading this O-MI/O-DF reference implementation enables end-users, developers,businesses and other ecosystem stakeholders to download and deploy an O-MI node/server to betterunderstand the standard specifications. They can jump straight into action by using the realrequest/responseexamplesthatcoverallaspectsofthesestandards. Thecurrentreferenceimplementation(i.e.,alsoreferredtoasO-MInodeinthisdocument)consistsoftwomainmodules:theAPIendpoint(O-MInodeserver)andaUI(webclient)asdepictedinFigure2-1.

Figure2-1O-MIreferenceimplementationAPIendpoint(O-MInodeserver):TheserverimplementsallO-MIbasicoperationsasdescribedinTable2-1.Inaddition,itmaintainsadatabasewheretheO-DFstructureisstored.Thisstructureisahierarchicalservicedescriptionmodelwithan‘Objects’elementas itstopelement,whichcancontainanynumberof ‘Object’sub-elements. ‘Object’ elements can have any number of properties, referred to as InfoItems, as well as‘Object’sub-elementsasshownintheFigure2-2.O-MI/O-DFmessagesareself-contained,meaningthatallthe informationnecessary toenable therecipient tohandle themessage iscontainedwithin themessageitself (e.g., the operation to be performed, the callback address, etc.). According to the standardspecifications, an O-MI/O-DF request is sent through a HTTP POST request to a public URL (e.g.,http://biotope.sntiotlab.lu:8080/ or https://otaniemi3d.cs.hut.fi/omi/node). The O-MI server acts as a‘’normal’RESTendpointformostoftheO-MIoperations,exceptforthesubscriptionmechanismthatallowseitherinterval-orevent-,orpoll-basedresponses(cf.Table2-1).



Figure2-2IllustrationoftheO-DFstructure

Operation Description Write UsedtosendinformationupdatestoO-MInodes.Read UsedforimmediateretrievalofinformationfromanO-MInode.Subscription • withcallbackaddress:thesubscribeddataissenttothecallbackaddress(basicallya

URLdifferentfromonethathassenttheoriginalrequest)attherequestedinterval.Twotypesofintervalsaresupported:interval-basedandevent-based;

• withoutcallbackaddress:dataismemorizedonthesubscribednodeaslongasthesubscriptionisvalid.Historicaldatacanberetrieved(i.e.polled)byissuinganewO-MIreadrequest(byspecifyingthesubscriptionID).

Cancel Usedtocancelasubscriptionbeforeitexpires.Table2-1MainMessagingInterfacesspecifiedintheO-MIstandards

UserInterface(webclient):AgraphicalinterfaceisaccessiblethroughtheO-MInodeserverwebsite(whichis nothing than the API endpoint, e.g., http://biotope.sntiotlab.lu:8080/ orhttps://otaniemi3d.cs.hut.fi/omi/node)asdepictedinFigure2-3.

Figure2-3WebpageoftheO-MIwebclient(hereforthenode’sURLhttp://biotope.sntiotlab.lu:8080)AnyIoTdata/serviceconsumerhasthreedifferentURLs,ashighlightedinFigure2-3:

• ThefirstURLenablestobetterunderstandhowtodiscover(andnavigatethrough)theO-DFtree,wheremessagesarebasedonHTTPGET requests. Forexample, inFigure2-4, thedata/serviceconsumerhasdiscoveredthatintheObject‘SnT’,thereisanObjectnamed‘IoTlab’,inwhichanObjectnamed ‘Netatmo’ is defined,which in turn contains 8 infoItems (i.e.,Object attributes),andsoon;



• ThesecondURListhecoreoftheUI,helpingdata/serviceconsumerstoplaywiththeO-MI/O-DFstandard specifications (i.e., sending/receiving and most importantly visualizing O-MI/O-DFrequests/responses);

• ThethirdURLjustprovidesanexampleofsyntaxoftheO-MI/O-DFrequest&response.

Figure2-4DiscoveryoftheObject‘Netatmo’intheObject(s)‘SnT’and‘IoTlab’

Fromadeliverableperspective,wewillrelymainlyonthesecondURLsinceitoffersauser-friendlyUIthatwillhelpthereviewertobetterfollowthedeliverable’sflow.ThisUI(giveninFigure2-5)aimstoguidestep-by-stepthedata/serviceconsumerwhencreatinghisownO-MI/O-DFrequest.Alltheuserinteractionoccurs in the left panel. To visualize the set of IoT data/services that are exposed/publishedby theO-MInodeserver, thewebclientsendsa request to theAPIendpoint (see ‘O-DFStructure’panel inFigure2-5).The end-user can therefore navigate through the O-DF tree and select as he/she sees fit the desireddata/service.Then,alloperationssupportedbytheO-MIstandard(see‘O-MIRequest’panelinFigure2-5)canbesolicitedbyspecifyingtheneeded‘parameters’.Inthesameway,thecorrespondingXMLrequestisgeneratedandsenttotheAPIend-point(theexamplegiveninFigure2-5showsthevaluefortherequestedInfoItem‘TemperatureIndoor‘).

Agent (wrapper):As depicted in Figure 1-1, the gateway level and particularly theO-MI node server can

implementoneormoreagent(s)/wrapper(s)topluganyexistingplatform/system/silototheO-MInodeand

populatetherealvalue(s)/service(s).(Theplatform’sAPIisusedtoaccessthedatasourceandwrapitinto

anunderstandableandstandardizedformat,namelyO-DF.)Fromanimplementationperspective,twotypes

ofagentsaredefined:internalandexternal.EithertheyrunonthesameJavaVirtualMachineastheO-MI

server(internalagent)ortheyrunasindependentprocesses(externalagent).Letusnotethattheexternal

agent can be located on the samedevice or a different one. External agents can be implemented in any

programminglanguagethatsupportstheTCP/IPlibrary.



Figure2-5O-MIwebclientUIafterclicking‘ReadAll’(withthepublishedO-DFtree),andselectingtheInfoItem

TemperatureIndoorintheObject(s)SnT,IoTlabandNetatmo



2.2. Discussionaboutthesecurityinthereferenceimplementation

Fromasecuritystandpoint,theO-MI/O-DFreferenceimplementationhasafirstlevelofaccesscontrol,

giving the possibility to the local administrator of the node to define what peer systems (IP-based) can

accesstheO-MInodeserverinwriteaccess(allpeersystemscan,bydefault,accessthewholeO-DFtreein

readonly).

A first step to secure the O-MI node consists in implementing an access control and authentication

mechanismforcontrollingwhatthirdpartyend-usersorsystemscanaccesstheO-MInodeserver.Thisstep

is detailed in the section 3-1. Then, an additionalmodule has beendeveloped to enable such third-party

persons/applicationstoaccesstheO-MInodethroughtheirapplication.Afirst token-basedaccesscontrol

solution isproposedanddescribed insection3-2.Fromaservicecatalogviewpoint–which iswherethird

partydeveloperswillsearchforvaluableIoTdata/serviceandgetthenecessaryinformationtoaccesstheIoT

data/servicefromaremoteO-MInodeserver(ifthenecessaryconditionsareinplace),aswillbepresentedin

greaterdetailinsection4–thefrontendandbackendsystemsshouldintegrateandhandlethisnewtoken-

basedmanagement solution. Finally, as a complementarymodule, a first privacymanagement strategy is

developedbasedonanonymizationtechniques,aswillbeexplainedinthesection4.2.

Figure2-6OverviewofthemodulesdevelopedinthisdeliverableD3.3ontheglobalpictureofthebIoTopeproject



3. SecuritymodulesfortheO-MInode

Thedevelopmentandimplementationstagesfollowthemicroservicearchitecturalstyle[11],whichisa‘fine-grained SOA (Service-Oriented Architecture)’ as defined by Adrian Cockcroft (a cloud architect atNetflix)inaconferencetalk.Toputitsimply,amicroservicearchitectureisadistributedapplicationwhereallmodulesareminimal independentprocesses interactingviamessages (i.e.microservices) [12].This isawayofstructuringmanyrelatedapplicationstoenablethemtoworktogetherratherthancreatingauniqueapplicationinwhichmodules-alsocalledmonoliths-aredependentontheexpectedapplicationtowhichtheybelong.

Given theabove, two independent securitymodules aredeveloped toenableend-users and/or third-partyapplications toaccess the resources (O-DFpayload)available through theO-MInode.Thecore ideahereistoavoidmakingbasicsecuritymistakesthatmostoftoday’sIoTdevicemanufacturersusuallymake.Forexample,communicationsshouldbeencrypted(referringtoacleartextAPI), localaccountsshouldnotuseeasilyguessedpasswords(backdooraccounts),andsoon.

3.1. Access control and authentication mechanism for the end-users of the O-MIwebclient

The objective is to provide end-users with a secure access to the O-MI webclient. To this end, the

followingrequirementsareidentified:• Access control of the resources: only users who have the access rights can perform the

correspondingO-MI/O-DFrequestactionsovertheservicetree;• Group-basedrules:allend-usersmustbelongtoagroup,andthenaccessrulesarespecifiedfor

eachgroup(neverforsingleusers).Everyend-usercanbeamemberofoneormoregroups;• PermissionsaccordingtotheO-MIverbs.Essentiallythisrequirementcanbetranslatedintothe

well-knowndistinctionbetweenROandRWaccessrights;• Recursivepermissionmechanism:canbeinheritedfromtheparent’sObject(sameasinmodern

filesystems)aswellasoverriddenforparticularchildren;• User & rule management interface: the system administratormust be able to control access

rightpoliciesthroughacentralizedinterface.

Toachievetheabovefeatures,thesecuritymoduledevelopedinbIoTopeconsistsoftwosub-modules,namelyadatabaseandanexternalauthenticationservice,whichmustprovideservicesfor:

• Permissionmanagement(throughaUI)toenabletheadministratortodefinetheaccessrights(accordingtotheregisteredusers),

• Anaccess control service to verifywhether a givenend-userhas the rightpermissionson therequestedinformation,

• Aseparatedatabasetostoreend-users/groupsandtheirrelatedaccessrightsettings;• Authentication to be made available ‘as-a-service’ with the use of the external web service

Auth0(http://auth0.com).

Beforeexplainingtheinteractionbetweenthesethreecomponents,letuspresentthedatabaseschemaused to store the access rules. As depicted in Figure 3-1, the database contains threemain tables:user,group and rule. A user is characterized by his username and email only, and belongs to a specific group(users and groups have relationship achieved through a helper table named USER_GROUP_RELATION).Accessrulesareassociatedtoagroup,whicharedefinedaccordingtothe:



• Dataobject: pathof theO-DFXML structure (e.g. ‘Objects/SmartHouse/FrontDoor’) named inthistablehierarchy_idorhid);

• Allowedoperation:cf.Write_Permissionscolumn,thatisaBooleanflag:0=readonlyor1=read&write;

• Objecttype:i.e.ObjectorInfoItemintheO-DFstandardonwhichmustbeappliedtherule.TheAdministratortableisahelpertablethatmaintainsalistofuserswithadminrightsandisfilledmanuallybytheserveradministrators.

Figure3-1Databaseschemaofthesecuritymodule

Tounderstand the interactionbetween these components, let us consider two scenarios depicted inFigures 3-2 and 3-3 depending on whether the user is or not the administrator. In both cases, the useraccesses theO-MIwebclient (UI) through aweb browser and needs to log in to be able to visualize andaccessthepartoftheO-DFtreetowhichitisallowedtoaccessto.Theauthentication(denotedbycircle1inFigure3-2) isdone fromtheAuth0service (enabling theuser to log inwithAuth0credentials)or throughsocialnetworkprovidercredentials(e.g.,Google,Facebook).Oncetheuserisloggedin,themoduleregisterstheuserinthedatabase(usernameandemailbeingobtainedfromtheAuth0response),therebycreatingausersessionaccordingly(i.e.asessioncookie).

Figure3-2Scenarioforauthenticatingtheuser‘Administrator’andgivingaccesstothepermissionmanagementinterface

APPEN

DIX

B.SEC

UR

ITY

MO

DU

LED

ATABA

SE61

FigureB.1:

Illustrationofaccess

controlandauthentication

modules

db



Whentheusertriestoaccessaspecificresource(permissionmanagementorO-DFinformation),theO-

MI node interacts with the access control service (cf. circle denoted by 2 in Figure 3-1 and 3-3), askingwhether‘userYcanaccessresourceXconsideringthetypeofrequestreceived’.Theservice’sanswer(‘YesorNo’)dependsontherulesthattheadministratorhasinitiallyspecified.Atamoretechnicallevel,aninterfaceof the O-MI node called AuthAPIservice is responsible to check whether the request contains a sessioncookieand,ifso,sendstheHTTPPOSTrequesttotheaccesscontrolservicewiththefollowingparameters:{listofobjects,user information,usersession}. If theanswer is ‘Yes’, thentherequestedO-DFresource isdisplayed to theuser (cf. circledenotedby3 inFigure3-3),otherwisean ‘Unauthorized’ responsecode isreturned(returncode401intheO-DFpayload).

Figure3-3ScenarioforauthenticatingauserandgivingaccesstotheO-DFresource

The above-mentioned interface looks like the O-MI webclient, except that it has been customized to

someextent, as shownon Figure 3-4. Through thisUI, the administrator canmanage users, groups (e.g.,creating,modifyingordeletinggroups)andassociatedaccessrights.The‘Save’buttonresultsinthestorageof the specified users/groups/rules into the database thanks to the permission management service (cf.circledenotedby3inFigure3-2).

Figure3-4Accessmanagementinterface.



When an OMI node’s administrator deploys this security module, the HTTPS protocol is used forencryptionandintegritycheckofallcommunicationsbetweenthewebbrowserandtheO-MInodeserver.Fromapracticalviewpoint,theOMInode’sadministratorcanconfiguretheportsrelatedtotheHTTPportoftheAuthAPIservice(inchargeofsendingthepermissionrequesttotheaccesscontrolservice)andtheHTTPSport (e.g. port 8089 in the Figure 3-4) to give access to the O-MI webclient and to the permissionmanagement interface. Letusnote that thismoduledoesnot substitute the security rulesdefinedat thenetwork/communicationlevel(firewall,Access-listinthenetworkinfrastructure,etc.).

3.2. SecureO-MI/O-DFinformationexchangeforthirdpartyapplications

Theobjectiveistoprovidethird-partyconsumerswithasecureaccesstotheO-MInodeserver.Tothisend,thetwofollowingrequirementsareidentified:

• Access controlof the resources:only third-partyapplicationowninga tokencanaccessO-DF-relatedresourcesaccordingtothetoken-relatedaccessrights,

• Fullauthorityofthethird-partyapplications:oncethethird-partyapplicationisallowedtousethetokenmanagementservice,itcangiveaccesstoitsend-usersthroughaspecifictoken.

Giventheaboverequirements,thesecuritymoduledevelopedconsistsoftwoservices,namely:

• Atokendeliveryserviceprovisiontoenablethird-partyapplicationtogetatoken(foraspecificend-user),

• A token verification service provision to verify if the consumer has the access rights on therequestedinformation.

LetusconsiderthescenariodepictedinFigure3-5,inwhichathird-partyapplicationwantstoaccesssomeO-DFresources.ItfirstneedstoaskforatokenbysendinganHTTPPOSTrequest(inaJSONformat)withtheparameters specified inTable3-1 (cf. circledenotedby1).The tokendelivery service returnsa JSONWebToken(JWT),whichisbasedonanopenstandard(RFC7519)definingacompactandself-containedwayforsecurely transmitting information as a JSONobjects betweenparties. This token consists of threedistinctparts,namelythe(i)header,(i)payloadand(iii)signature,aspresentedingreaterdetailbelow.

Figure3-5Scenarioforgivingaccesstoathird-partyapplication

Parameter Description clientId Theidentifierofthethird-partyapplicationgivingbytheO-MInodeclientSecret Thesecretkeyofthethird-partyapplicationgivingbytheO-MInodehid ThepathintheO-DFXMLstructure,e.g.‘Objects/SmartHouse/FrontDoor’username TheusernameoftheO-DFinformationrequestervalidity Thetime(insecond)afterwhichthetokenwillexpireTable3-1Parametersforaskingthetoken



Header:itspecifiesthemessageauthenticationalgorithm,e.g.{‘alg’: ‘HS256’}meansthatthemessageisauthenticated and integrity-protected using the HMAC SHA-256’s algorithm. The corresponding JSON is(Base64Url)encodedtoformthefirstpartoftheJWTasfollows:eyJhbGciOiJIUzI1NiJ9.Payload:Thisisthesecondpartofthetokencontainingtheclaimsthatarestatementsabouttheexchange.Forinstance,theimplementedmoduleusesthisfollowingpayload:{ ‘hid’: ‘Objects/SmartHouse/FrontDoor’, ‘iss’: ‘ominode’, ‘exp’: 1484905924, ‘iat’: 1484895924, ‘username’: ‘test’ } wheremetadata‘path’(oralsonamedhidinprevioussections)representsthepaththatcanbeaccessedto(obtainedintherequest),‘iss’thenameoftheissuer(heretheOMInode’sname),‘exp’thedatebywhichthetokenwillexpire(computedbasedontheissuedateetvalidityrequested), ‘iat’ thedatebywhichthetokenisissued,and‘username’(obtainedintherequest)forstatisticalpurposes.ThisJSONisalsoencodedtoformthesecondpartoftheJWT,resultingin:eyJoaWQiOiJPYmplY3RzL1NtYXJ0SG91c2UvRnJvbnREb29yIiwiaXNzIjoib21pbm9kZSIsImV4cCI6MTQ4NDkwNTkyNCwiaWF0IjoxNDg0ODk1OTI0LCJ1c2VybmFtZSI6InRlc3QifQ Signature This is created by taking the encoded header, payload, secret and algorithm specified in theheader.ItmakesitpossibletoverifyboththattheJWT’ssenderreallyistheentityitpurportstobeandthatthemessagewasnotchanged/corruptedalongtheway.ThereturnedJWTwouldthereforebecome:eyJhbGciOiJIUzI1NiJ9.eyJoaWQiOiJPYmplY3RzL1NtYXJ0SG91c2UvRnJvbnREb29yIiwiaXNzIjoib21pbm9kZSIsImV4cCI6MTQ4NDkwNTkyNCwiaWF0IjoxNDg0ODk1OTI0LCJ1c2VybmFtZSI6InRlc3QifQ.yo330HJ9oegg0-1QYlnrdoitvzU7OjKRAmOQt18kvWs The third-party application sends theO-MI/O-DF request to theAPI endpoint (via anHTTPPOST request)includingtheJWTastheAuthorizationheader(cf.circledenotedby2inFigure3-5).Thetokenverificationservice checks whether the JWT is a valid one and, if so, allows the third-party access to the protectedresources(cf.circledenotedby3).



4. Security&PrivacywiththeservicecatalogueIoTBnB

Letusrecallthatthemainobjectiveoftheservicecatalogue(IoTBnB)istoenablepersonand/orsystemto[13]:• IoT data/service producers (consumers of goods, citizens, municipalities, businesses or other legal

entities) for having thepossibility for joining the bIoTope ecosystem community anddescribing –based on O-MI/O-DF – what personal IoT data/services from theirown digitalenvironment areavailable, and how to query/call them, while being able tocontrol howandby whomthosedata/servicescanbeaccessed,processed,re-used,re-published,etc.;

• IoT data/service consumers (businesses areof coursethe first parties concerned like integratorsdevicemanufacturers, software companies…) with the possibility and motivation for joining themarketplacecommunity,searchingfor,andconsumingvaluableIoTdatastreamsand/orserviceswiththeobjectivetore-use/composethem–undercertainconditions/IPRsandpotentialfinancialreturns–intonewandsustainabledevelopmentsthatfulfilluntappedneedsandapplications.

It is important tounderstandthat IoTBnBdoesnotactasaClouddatastoragecenterwhere IoTdata

generatedbysmartconnectedobjectsisstored,butratherasaserviceregistrywebspace(ormarketplace)where the ‘descriptions’ of IoT data/services are stored, indexed and searchable. Then, only once theconsumerwants, and is allowed to access it, IoTBnB plays the role of third-party application, putting thepublisherandconsumerinrelationwitheachothersothatdata/servicescanbeperformedinapeer-to-peermanner(withouttransitingthroughIoTBnB).Havingsaidthat,theobjectiveofthissectionistodetail:

• How an IoT data/service provider can expose his/her own data/services to the service cataloguewhilebenefitingfromthesecuritymodulepreviouslyintroduced;

• HowanIoTdata/serviceconsumercanusetheservicethathe/shehaspurchasedfromtheservicecatalogue;

• Howtheservicecatalogcananonymizeanend-useroranapplicationasfirstlevelofprivacy.

4.1. SecuritymanagementwithIoTBnB

Fromasecurityperspective, IoTBnBshouldbeabletoobtaintheJWTsfromtheO-MInodethatholds

theIoTdata/servicetoprovideittotheconsumerofthatdata/services.Todoso,thewebsiteneedstohaveaccesstotheseller’sAPItogettokenson-behalfofthebuyersasathird-partyapplication.

Figure4-1Sellerscenarioforpublishing/sellinghis/herownIoTdata/servicethankstotheIoTBnBmarketplace



Figure4-1describes thescenario fromtheperspectiveofan IoTdata/servicepublisher,whowants tomakesearchablehis/herdata/service in theservicecatalogue.Theassumption in this scenario is thatthispublisherhasimplementedthesecurityforthird-partyapplication(asdescribedinsection3.2.)andsigned-uporloggedintotheservicecatalogue(cf.circledenotedby1inFigure4-1).AsshowninFigure4-2,IoTBnBrequeststheauthentication-as-a-servicecomponent(i.e.Auth0service)toobtainthepublisher’sprofile(cf.circles denoted by 2 and 3). In the current version of IoTBnB, only the username and email address aredisplayedandstored(cf.,ProfilepageinFigure4-3).Followingthisstep,thedata/servicepublisherfillsouttheformabouttheneededinformationrelatedtohisO-MIserverandthesecuritymodule(cf.circlenumber4).Figure4-4presentsthisforminwhichtheO-MInode’sURL,nameandlocationarerequired,aswellastheURLofthesecuritymodule,clientIDandsecret.Atthisstage,IoTBnBcanrequestatokentoaccessthewhole O-DF structure (cf. circles denoted by 5 and 6) to be able to harvest and index3the set of IoTdata/services exposed/described by the publisher’s O-MI node server. Let us note that this token is notneeded if the seller does not implement the security module. Then, the publisher can select the O-DFdata/servicesthathe/shewantstopublish/exposethroughthepublicservicecatalogue(cf.circledenotedby8),alongwithaspecificpriceforaccessingit,asemphasizedthroughFigure4-5(intheproject,aframeworksupportingcrypto-currencytechnologieswillbetested,andparticularlyconsideringtheBitcointechnology).

Figure4-2Userauthenticationphasefromtheauthentication-as-a-servicecomponent,i.eAuth0

Figure4-3UserProfileintheservicecatalogue

3TheindexingiscarriedoutbasedonOpenDataSoftSoftware-as-a-Serviceplatform,whichcanbeaccessedaslongasthetokenprovidedbyIoTBnBisvalid(cf.circlesdenotedby7’and7’).



Figure4-4O-MIserverinformationfromasellerperspectiveintheservicecatalogue

Figure4-5SellerpublisheddataintheIoTBnBwebsite

Now,letusconsiderthebuyerviewpoint.

Figure4-6Buyerscenarioforsearchingfor/buyingdata/serviceintheIoTBnBwebsite



Figure4-6describeshowan IoTdata/service consumer can search for a data/service through the IoTBnBservice catalog (API currently being specified), buy it and consume it. Similarly to the publisher, theconsumer of IoT data/services can sign-up on the service catalogue (cf. circle denoted by 1) via theauthentication-as-a-servicecomponent(cf.circlesdenotedby2and3).ThefirstpageofIoTBnBdisplaysallthe indexed data/services (developed based on the Opendatasoft widget/component suite), where suchdata/servicescanbesearchedinamultimodalmanner,e.g.:

• Spatial/Temporalsearch:onemaywanttosearchforserviceswithinageographicalarea;

• Keyword search: one may want to search for services falling in a specific sector (e.g., mobility,healthcare,building,etc.).SuchafeaturerequiresanefficientandscalablewaytoindexIoTservices,which is partly dependent onwhat semanticweb vocabularies have beenused in theO-DF servicedescriptionmodel/tree.

• Reputation search: onemaywant to search for a service ensuring a certain level of quality,whichcomprises various dimensions such as (i) data quality: quality of sensor data streams or moreadvanced services like how accurate a failure prediction algorithm is, (ii) service owner reputation:thirdpartydevelopersbeingabletoleaveareviewaboutwhetheragivendatastreamworkswell,orthepublisher’sreactivitywhenaskedquestions,etc.SuchareputationwillbecomputedthankstotheservicequalityassessmentframeworkdevelopedinT3.C;

• ContractualtermorTechnologysearch:onemaywanttosearchonlyforIoTdata/serviceproducersthatmake available data/service for free, or are compliantwith one ormore crypto currencies, ordata/servicesthatarecompliantwithspecificIPRpolicies(i.e.,licensetype,etc.).

Figure4-7 showsanexamplewhere theend-usershave searched for thekeyword ‘moisture’, resulting intwoavailabledata/services.Letusconsiderthattheconsumerwishestobuythefirstone:itisaddedtothecart,theaccessibilitydurationisspecified(cf.Figure4-8),thepaymenttransactionisperformedinanad-hocmannerbetweenthedata/serviceconsumerandpublisher,andmonitoredbyIoTBnB(cf.Figure4-9).Ifthetransaction is successful, IoTBnB gets a token from the data/service publisher (based on the informationentered by the publisher at the registration phase), which is then given/displayed in the consumer’sdashboard(wherehe/shecansee/usethesetoftokensrelatedtoallthepurchaseddata/services,asshownin Figure4-10). Then, the IoTdata/service consumer can start exchanging/requestingdata/servicesusingtheO-MIoperationswithremotepublisher’sO-MInodeserver(thetokenbeingincludedintheHTTPheaderrequest). This paves the way to a more secure and trustable data exchange following a ‘human centric’securitymodel.



Figure4-7Exampleofsearchingbasedonthekeyword‘moisture’

Figure4-8Exampleofthebuyercart

Figure4-9Paymentstep(notimplementedyet)



Figure4-10Buyerdashboardwiththepurchaseddata/serviceandrelatedtoken

4.2. PrivacymanagementstrategieswithIoTBnB

Fromtheservicecatalogueperspective,oneofthemainconcernsistoensuretheprivacyofitsusers,and especially in the exchanges between seller and buyer. Indeed, as seen in the previous sections,when a buyerwants to consume purchased data, he/she uses a token inwhich a username (e.g. anemail address) is included and requested by the O-MI node. This constitutes a personal identifiableinformation (PII),which canbe considered sensitive. The service catalogueneeds therefore to ensurethatthesellerdoesnotobtainthebuyer’sPIIwhenthebuyergainsaccesstoODFresources.Thereareseveral techniques that attempt to protect privacy of an individual such as anonymization,pseudonymization, encryption and so on. The first techniques are the approaches mainly used (inparticularinthehealthcaresector).

Anonymity can be defined as ‘the state of being not identifiable within a set of subjects, the

anonymityset’[14].Theobjectiveoftheanonymizationisthereforetoremoveofasmuchinformationasneededtoconcealtheuser’sidentity.Forexample,PIIsuchasname,zipcode,dateofbirth,addressandsoonwouldberemovedwhenthereisnoneedforthem[15].Pseudonymizationcanbedefinedastheuseoffalsenames(orpseudonyms)intheprocessofmaskingtheuser’sidentitysothatinformationrelatingtothisusercanbeusedwithoutknowingtowhomtheinformationrelates[16].

Figure4-11Buyerscenarioforsearchingfor/buyingdata/serviceintheIoTBnBwebsitewithusernameanonymization



Asa first levelofuserprivacy, theobjective is to implementpseudonymizationandanonymizationtechniques in the service catalogue. These can be implemented either as internal or external in theIoTBnB service catalogue. Based on the scenario depicted in Figure 4-6, Figure 4-7 shows how ananonymizationservicecanbeeasilyintegrated.Letusnotethatthisservicewillbeactivatedonlywhenthebuyerwantstobeanonymous.(Thisoptionwillbemadeavailablethroughhis/herIoTBnBdashboardlater.) In that case, after having paid for the data, the service catalogue requests an anonymisedusername to the anonymization service (cf. circle denoted by a). Based on the input parameterusername (i.e. the buyer’s email address), the service can return an anonymized username (cf. circledenotedbyb).

A first strategy, named pseudonymization, consists in binding the username to a pseudonym. As

depicted in Figure 4-12, every username in the IoTBnB domain is associated to a pseudonym in theanonymization service domain. For example, the user with the email address [email protected] will bemapped to thepseudonymbuyer-2.This translation is then stored ina table tobeable to return thesamepseudonymforthesameuser.Thesellercanthereforecomputeusagestatistics–ifhe/shewants.Inthatpurpose,thesellercantrackthedataaccessbyreadingafile–namedanonymization– inthelogs/directoryof theO-MInode.This file consistsof twopiecesof information: (i) theuser identifier(anonymizedornot)and(ii)thepathoftheconsumedO-DFresource.

Figure4-12Pseudonymizationidea

Asecondstrategy,namedk-anonymization,consistsinmappingtheusernametoa‘quasi-identifier’that refers to a group where there are at least k records with the same occurrence. According to thenumberofrecordsinthetable,eitherthesuppressionmethodorthegeneralizationmethodwillbeapplied.Thesuppressionmethodassociates theusernametoaspecific character suchas, forexample,anasterisk(‘*’). The generalizationmethod consists inmapping the username to a category name to k records. Forexample, the anonymization service could rely on the institution-based categories; this means that thechosen category will be the name of the institution given in the email address (i.e. the word after thecharacter‘@’andbefore‘.’).Inthiscase,Figure4-13showsthebothmethodswhere:

• theusernames [email protected]@aalto.fiarebothreplacedto‘*’followingthesuppressionmethod,sincetherearenorecordswiththesameinstitution(eitherunioraalto);

• the usernames [email protected] and [email protected] are translated to free following the generalizationmethod.

Let usnote thatonly2-anonymity is ensured since there areonly 2 recordswith the same category. TheparameterkwillbelargerwhenthenumberoftheIoTBnBusersincreases.However,thisparametercouldalsobechosenbytheuserinhis/herdashboard.



Figure4-13k-anonymizationidea

Asofthetimeofwriting,the implementationchoicesarenotset instonebutthebothapproaches

explainedhavebeen implementedasa feasibilitystudy.However theprivacy isstillachallenge inthebIoTopeeco-system,andmorebroadlyintheIoT.Consequently,eventhoughthisgivesafirstoverviewoftheprivacystrategiesthatcouldbeimplementedinthenextreleaseoftheIoTBnBservicecatalogue,a further study (and a more complete state-of-the-art) would be necessary to maketherightimplementationchoiceforfuturedevelopments.



5. Conclusion

This deliverable provides insight into the two first building blocks/modules to secure informationexchangesatthegatewaylevelfortheend-usersandthethird-partyapplications.Thefirstmodulereliesonthe external authentication service Auth0,which enables end-users to authenticate themselves in theO-MI/O-DFreferenceimplementationwebclientusingtheirAuth0orsocialnetworkprovidercredentials.Thesecond module enables third-party applications to access O-DF resources through the REST interface byusingaJWT.Thisfirstreleasegivesfullauthoritytothethird-partyapplicationstomanagetheaccessright.However, amore fine-grained version could benefit from the twomodules to verifywhether a particularend-user(i.e.thethird-partyapplicationbasedonausernamewhichwillbeincludedinthetoken)isallowedto access a particular resource (included in the token as well). This would need that the modulescommunicatewitheachother. Inaddition,accesscontrolpoliciescouldbemoreadvancedbyconsideringoneormore‘Contexts’relatedtoahumanbeingoraphysicalobject(e.g.location,situation,leveloftrustorreputation of surrounding entities...) [17]. In the current version of the O-MI/O-DF referenceimplementation, a very basic level of context security based on the IP address for the specific writeoperationisimplemented.

Thisdeliverablealsohighlightshowthesecuritymodule isusedwiththebIoTopeservicecatalogue(IoTBnB).Thethird-partyapplicationIoTBnBcangetatokenfromthedata/servicepublisher(i.e.theseller)onbehalfoftheconsumer(i.e.thebuyer).Theconsumercanthereforesee/usethesetoftokensrelatedtoallthepurchaseddata/servicesinhis/herdashboard.Inaddition,theservicecatalogueofferafirstlevelofprivacytotheconsumer,whichcanbeanonymous–ifhe/shewantsandaccordingtohis/herdesiredlevel–fromthepublisherviewpoint. Infuturework,thestateoftheartoftheprivacymodels/strategies(e.g.,k-anonymisation) at research level aswell as at practical levelwill be further studied to givemore privacyoptionstotheusers.Thiswillthereforeleadtoamorecomplete‘Humancentric’securityandprivacymodel.



6. References

[1] Drozhzhin, A. (2015). Internet of Crappy Things. https://blog.kaspersky.com/internet-of-crappy-things/7667/.

[2] Stanislav, M., Beardsley, T. (2015). HACKING IoT: A Case Study on Baby Monitor Exposures andVulnerabilities.Whitepaper(Rapid7).

[3] WindRiver(2015).SecurityintheInternetofThings.Whitepaper

[4] Sicari,S.,Rizzardi,A.,Grieco,L.A.,Coen-Porisini,A.(2015).Security,privacyandtrustinInternetofThings:Theroadahead.ComputerNetworks,76,146-164.

[5] Ahlmeyer,M.,&Chircu,A.M.(2016).SecuringtheInternetofThings:aReview.IssuesinInformationSystems,17(4).

[6] Weber, R.H. (2015). Internetof things: Privacy issues revisited.Computer Law&SecurityReview,31(5),618-627.

[7] Peppet, S.R. (2014). Regulating the internetof things: First steps towardmanagingdiscrimination,privacy,securityandconsent.Privacy,SecurityandConsent,TexasLawReviews.,2014,93,85-173

[8] Roman, R., Zhou, J., Lopez, J. (2013). On the features and challenges of security and privacy indistributedinternetofthings.ComputerNetworks,57,2266–2279.

[9] Vasilomanolakis, E., Daubert, J., Luthra,M., Gazis, V.,Wiesmaier, A., & Kikiras, P. (2015). On theSecurityandPrivacyofInternetofThingsArchitecturesandSystems.InIEEEInternationalWorkshoponSecureInternetofThings(SIoT).

[10] Miorandi,D.,Sicari,S.,DePellegrini,F.,&Chlamtac,I.(2012).Internetofthings:Vision,applicationsandresearchchallenges.AdHocNetworks,10(7),1497-1516.

[11] Fowler,M.&Lewis,J.Microservices.ThoughtWorks,2014.

[12] Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, M., Montesi, F., Mustafin, R., & Safina, L.(2016).Microservices:yesterday,today,andtomorrow.arXivpreprintarXiv:1606.04036.

[13] (2016).D4.1EdgeDataStorageandIntelligentFiltering.bIoTopedeliverable.

[14] Pfitzmann, A. and Kohntopp,M. Anonymity, unobservabilityn and pseudonymity – a proposal forterminology.LecturesNotesinComputerSciences.1-9.2001

[15] Kalloniatis, C., Kavakli, E., &Gritzalis, S. (2005, December). Dealingwith privacy issues during thesystemdesign process. InSignal Processing and Information Technology, 2005. Proceedings of theFifthIEEEInternationalSymposiumon(pp.546-551).IEEE.

[16] Pommerening, K., & Reng,M. (2004). Secondary use of the EHR via pseudonymisation.Studies inhealthtechnologyandinformatics,441-446.

[17] Hulsebosch, R. J., Salden, A. H., Bargh, M. S., Ebben, P. W. G. and Reitsma, J. (2005). Contextsensitive access control, Handbook of Research onWireless Security. In: Proceedings of the ACMsymposiumonAccesscontrolmodelsandtechnologies,111-119.

deliverable d3.3 context-sensitive security,...

Documents