DELIVERABLE This project has received financial support from the European Union Horizon 2020 Programme under grant agreement no. 688203. D3.3 Context-Sensitive Security, Privacy Management, Adaptation Framework v1 Project Acronym: bIoTope Project title: Building an IoT Open Innovation Ecosystem for Connected Smart Objects Grant Agreement No. 688203 Website: www.bIoTope-project.org Version: 1.0 Date: 31 March 2017 Responsible Partner: UL Contributing Partners: UL, Aalto Dissemination Level: Public X Confidential – only consortium members and European Commission Services Ref. Ares(2017)1979548 - 17/04/2017
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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
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:
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...).
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]:
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:
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).
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...).
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.
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.
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).
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.
• ThesecondURListhecoreoftheUI,helpingdata/serviceconsumerstoplaywiththeO-MI/O-DFstandard specifications (i.e., sending/receiving and most importantly visualizing O-MI/O-DFrequests/responses);
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
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
• 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:
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).
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).
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).
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.).
• 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.
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).
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;
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-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.:
• 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.
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
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:
Let usnote thatonly2-anonymity is ensured since there areonly 2 recordswith the same category. TheparameterkwillbelargerwhenthenumberoftheIoTBnBusersincreases.However,thisparametercouldalsobechosenbytheuserinhis/herdashboard.
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.
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.
[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).
[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.