Embed Size (px)
Citation preview
SharingmHealth DataviaNamedDataNetworking
Haitao Zhang1, Zhehao Wang2, ChristopherScherb3,ClaudioMarxer3, JeffBurke2, Lixia Zhang1,ChristianTschudin3
1.UCLAIRL2.UCLAREMAP3.UniversityofBasel
1
Context(bonusslide)
2Gartner,2014
Consumer-facingmHealth applications.Over13,000availableforiPhone,over6,000availableforAndroid.
3
Prakash,R.Adoptionofblock-chaintoenablethescalabilityandadoptionofAccountableCare.2016.http://www.hhs.gov/about/news/2016/08/29/onc-announces-blockchain-challenge-winners.html
Motivation(bonusslide)
<=probablynotsustainable,almostcertainlynotempoweringifunifiedviaone-provider-to-rule-them-all.
OpenmHealthFollow-uptoparticipatorysensingworkEcosystemforhealthdatasharing- Leverageseverydaymobiledevices-Definesdataexchangeasthe“thinwaist”- Featuresuser-controlledandprivacy-aware dataexchange
LimitationsofTCP/IP-basedOpenmHealth-Architectureout-of-syncwiththevisionoftheapp- (Administratively)centralized approachto datamanagement:A resourceservermanagesdatapointresources
- Connection-basedsecuritymanagedbyservices4[1]D.Estrin andI.Sim.OpenmHealth architecture:anengineforhealthcareinnovation.
Science,330(6005):759-760,2010.Also,http://openmhealth.org.
WhyuseNDNforOpenmHealth?
NDNandOpenmHealthsharedataexchangeasthe“thinwaist”– oneatapplevel,oneatnetworklevel.- Intuition:NDNshouldbeabetterfit.
Also,modelofsecuringdataclosetocaptureparticularlyusefulfora“ecosystem”withmanyactors.
5Sim&Estrin,2010
NDNFit “ProofofConcept”Totheuser,asimplefitnessapplication.Behindthescenes,builtonaprototypeOpenmHealth ecosystemusingNDNinsteadofTCP/IP.Focusesontime-locationdata
- Timestampanditscorresponding(longitude,latitude)pair
- Annotationswithactivityclassification- Extend to other datatypesin the future
Goals- Anextensiblesystem to collect, analyzeand share users’ physicalactivitydata
- An ecosystemofcomposable services- Actuallyimplementauthenticationandaccesscontrol
Thedatacaptureapp
Ecosystemcomponents(borrowedfromOpenmHealth)-Datastorage units(DSU)-Data processing units(DPU)-Data visualization units(DVU)-Mobilecaptureappandconfigurationwebsite- “Local”authorizationmanager
Applicationarchitecture
7
register
User’s mobile devicecapture
appidentity
managerauth
manager
Data storage unit (DSU)
Data processing unit (DPU)
sync
sync
Data visualization unit (DVU)
Configuration website
namespace mgt
system config
register &configure
sync
registerregister
<=Eachrunbypotentiallydifferentorganizations.
First,names:NamespaceDesignGoals
• Namedatafromhealth applicationperspective- Prefixtoidentifythedataecosystem- Componentto identify the data owner- Components to classify data into different types- Fundamentaltypesincludetime-serieslocationtraces
• MakecommondatarequestsusingonlyInterest-Dataexchange• Authenticityofhealthdataiscritical: reflectthetrustrelationshipsbetweendifferentcomponents• Health data is highly private: enableusers tocontrol accesstotheirtheir data withoutrelying onthird party services
8
/org/openmhealth
<user-id> <service-id>(DPU, DVU)
key
<version>
key
<version>
key
<version>
devices
<device-id>
key
<version>
Dataread
fitness
Physical_activity
D-KEY E-KEYfitness
Physical_activity D-KEY E-KEY
D-KEY E-KEY
<start_timestamp_hour> <start_timestamp_hour>
<end_timestamp_hour> <end_timestamp_hour>
FOR
<consumer-id>
ENCRYPTED PRIVATE KEY
PUBLIC KEYDATA OBJECT
time_location bout
<timestamp> catalog C-KEY
<segment>(opt.)
DATA OBJECT
<timestamp>
<version>
DATA OBJECT
<start_timestamp_hour>
<end_timestamp_hour>
<E-KEY name>
SYM KEY ENCRYPTED
BY E-KEY
time_location D-KEY E-KEY
… …
… …
……
FOR
…
Namespace
9
Identify theecosystem
Trust anchor
User and componentidentifiers
healthdatasources
cryptographicidentity(trustrelationship)
Raw dataand catalogs
Access control
Data types
/org/openmhealth/haitao/data/fitness/physical_activity/time_location/20160526T161300
user-id data-typeprefix timestamp
/org/openmhealth/haitao/data/fitness/physical_activity/time_location/catalog/20160526T160000
user-id data-typeprefix timestampcatalog component
Dataandcatalognaming
10
Time-locationdatapacketname
-Namedatper-minutegranularity- Fetchedusingexactnamesorusingselectors,freshness
Catalog– manifest-styleobjectproducedatknownintervals
- Envisionedforconsuminghistoricaldataorlargerdatatransfers- Packetize data names/timestampsonanhourlybasis
Identityandtrustmodel• Designgoal:makingtrustofthedatainherentinthedataitself,asopposedtotiedtoserviceorconnection
• Trustmodeldefinition- Usesschematized trust1:definesapplicationtrustviaasetofrelationshipsbetweendatanamesandkeynames
• OpenmHealth trustmodel- User asthe rootoftrust for her/hisownhealthdata.- Hierarchicalfortheuser’sdata;probablymorecomplexforrelationshipsamongusers.
- AhierarchicaltrustmodelfitswellforthepilotNDNFit’scontext,e.g user->device->app->data.
11
[1]Y.Yu,A.Afanasyev,D.Clark,V.Jacobson, L.Zhang,etal.SchematizingTrustinNamedData Networking.InProceedingsofthe2ndConferenceonInformation-CentricNetworking.ACM,2015.
TrustinNDNFit
12
Hierarchicaltrustmodelforcaptureddata
Mobile“identitymanager”appmanagesuser,deviceandotheridentities,enablestheirselectionbytheuser.
/org/openmhealth/<user-id>/<device-id>/<app-id>
/org/openmhealth/<user-id>/<device-id>/
/org/openmhealth/<user-id>/
/org/openmhealth/
signed by
signed by
signed by
/org/openmhealth/<user-id>/<data-type>/<timestamp>signed by
Accesscontrol• Problem:OAuth-style authenticationis asignificantpainpointincurrentOpenmHealth- Requiresmorefederationthanreasonableordesirable- DesiretocreateprocessingchainsDSU->DPU->DPU->DVU
• Designgoals:- Achieving accesscontrolindependentofhowdataisexchanged- Enablinguser-defined access control granularity
• Name-basedaccesscontrol(NAC)1 developedwithNDNFitasa usecase- Dataisencryptedatgenerationtime, instead of only when it istransmitted
- Authorizationmanager(controlledbytheowner)grantscomponentsaccess to owner’sdata byproperly naming,signing,andencrypting keys
13[1]Y.Yu,A.Afanasyev,andL.Zhang,“Name-BasedAccessControl,”NamedDataNetworkingProject,TechnicalReportNDN-0034,October2015.
Logicalrolesandkeys• Owner – viaauser-controlled authorizationmanager- Createsasymmetrickeypairs(key-encryptkeyKEKandkey-decryptkey KDK– theconsumption credential key pair)capableofdecryptingcontentkeys(C-KEYs)
• Producers – e.g.,captureapp,DPU- Produces data andcatalogs,encryptedbyC-KEYs(contentkeys)foragivenminimumaccessunit,MAU,e.g.hourly
• Consumers – e.g.,DPU,DVU- PublishesitscertforownertouseinencryptingKDK
• Storage– e.g.,DSU- Storesdataintheuser’snamespace,doesn’tnecessarilyhavetobeabletodecryptit
14
NACin NDNFit
15
Authorization manager(on behalf of users)
Capture app(dataproducer)
DVUorDPU(dataconsumer)
KEK KDK
Public Key
Private KeyDataMAU
C-KEY
Data
KDK
C-KEY
Consumptioncredential(KEK/KDK)providesonelevelofindirection
Handleon-demanddataprocessingw/NFN
• Goal:Userscomposetheirownhealthdataprocessingnetworks(forexample,seeC.Marxer talk)
• DPU design goals- Entrustedbyuserstoconsumerawdataandproducederiveddataondemand- Easyadaptationtoevolvingprocessingfunctionalities
• ApplyNamedFunctionNetworking(NFN)1-Uses processingexpressions (named function +parameters) as interest, or “name the result”-NFN-enablednodes take care of how the result iscalculated
16[1] M.Sifalakis,B.Kohler,C.Scherb,andC.Tschudin. AnInformationCentricNetworkforComputingthe DistributionofComputations.InACMICN'14,pages137-146,2014.
AccesscontrolinNFN-basedDPU
17
• DesirenativeNAC(oraccesscontrolmoregenerally)supportinNFN.• Notthereyet- inthecurrentimplementation,useaname rewriter,which-Maps NDN name toNFN name- Takes care of NACaccesscontrol mechanism
!
/func/code
"
#
!
DPU
DSU
Execution Environment
#
Complex Expression (Interest)
KDK
Secured Result (Data)
"KEK
!
Input DataFunctions
NAC
Summary• AprototypemHealth ecosystemoverNDNwithdataauthenticationandaccesscontrol• Nameddataseemstosimplifythecreationofuser-centereddataecosystems• Securingdatadirectlyseemspromising
- CanwerealizetypicalICNstory?Reducevulnerabilitiesemergingfromrelyingonunderlyingtransportlayersforsecurity
- Seemslikeit:Placesmorecontrolwithuser,potentiallyeasiertoachievemorechoice.
• Namespacedesignedsuchthat:- Enablesbothdirectdataaccessandcatalogs to facilitatedataretrieval
- Definesahierarchicaltrustmodel;theappuses “schema”basedondataandkeynamestructuretoexpresstrustrelationships
- Enablesname-basedaccess controlmechanismatanapplication-definedgranularity
- IncorporatesNamedFunctionNetworking forextensibleanddistributeddataprocessing
18
Openchallenges• Atthebottom:Balancingthetusslebetweenapplication’sandnetwork'srequirementsonnaming.• Atthetop:Engaginguserswiththelevelofdecision-makingthatispossible.• Inthemiddle:ImprovingusabilityofNACfordevelopers– whatistarget?• Bestmethodtohandlenameconfidentiality:namesleakuserinformation.• Otheraccesscontrolmodels:WhataboutABE&othertechniques?• BestwaytoevaluateincomparisonwithIP?
19
