Identity-Defined Privacay & Security for Internet of Things
-
Upload
wwwpingidentitycom -
Category
Technology
-
view
56 -
download
0
Transcript of Identity-Defined Privacay & Security for Internet of Things
What’s driving IoT• The sensor legacy. Sensors and remote monitoring tools have
existed for decades, in a field known as machine-to-machine (M2M) communications, monitoring, and control.
• Broadening connectivity. Mainstreaming of home wifi, 4G mobile, low-power wireless standards such as Bluetooth and ZigBee are enabling just about everything to be connected together.
• The cloud and big data. Cloud computing and big data allow the massive data created by things to be sifted, processed, and acted upon
• APIs. Distributed, loosely coupled, transactional approaches in software design are allowing things to exist and communicate autonomously alongside internet-based services
Market
• Market size for IoT will be $290 billion by 2017, and growing at 30 percent per year (MarketsandMarkets)
• 31 billion internet-connected devices will exist by 2020 (Intel)
• A family of four will move from having 10 connected devices in 2012 to 25 in 2017 to 50 in 2022 (Intel)
Privacy & Security ChallengeMost of the devices in the Internet of
Things will be used in two broad areas:– Critical Infrastructure - power
production/generation/distribution, manufacturing, transportation, etc.
– Personal "infrastructure" - personal medical devices, automobiles, home entertainment and device control, wearables, etc
Demandssecurity
Demandsprivacy
Security requirements• Confidentiality. Protecting data from being inappropriately
accessed by unauthorized actors. Often manifests in authorization policies & encryption
• Integrity protecting data or methods from modification or deletion by unauthorized parties. Often manifests in digital signatures
• Authentication. Verifying the identities of actors as they interact with each other to ensure that malicious parties are not given inappropriate permissions
Security challenges of the IoT• Life and death implications• Scale• Heterogeneity• Storage, processing, and connectivity constraints• Usability implications of screenless devices• Complex relationships between users & devices• Implications of gateways for end-to-end security
Privacy requirements• Transparency helps people understand who knows what about them —
give people information on how their data is to be used, with whom it is shared with; how long is it held; etc
• Intervenability is the ability for users to view, change, correct, block, revoke consent, and delete personal data stored by providers & applications.
• Unlinkability is about the separation of informational contexts, such as work, personal, family, citizen, and social. It’s about preventing undesired linkages across different contexts.
Authentication & Authorization Model
• IoT Actors authenticate by presenting security tokens on their calls/messages to each other
• Tokens represent relationship between the relevant user and the calling actor (and any consents/permissions associated with that relationship
• Upon receiving a message, an actor validates the token to verify the request is consistent with the relationship/permissions
• If consent is removed, token is revoked, and access disabled
OAuth 2.0 & OpenId Connect 1.0• OAuth 2.0 is an IETF authentication & authorization framework for
securing application access to RESTful APIs• OAuth allows a Client to send an API query to a Resource Server (RS),
the application hosting the desired information, such that the RS can authenticate that the message was indeed sent by the Client.
• The Client authenticates to the RS through the inclusion of an access token on its API call—a token previously provided to the Client by an Authorization Server (AS).
• In those scenarios that the API in question protects access to a User’s identity attributes, it may be the case that the access token will only be issued by the AS after the User has explicitly given consent to the Client accessing those attributes.
• OpenID Connect 1.0 profiles and extends OAuth 2.0 to add an identity layer—creating a single framework that promises to secure APIs, mobile native applications and browser applications in a single, cohesive architecture.
Representative IoT architecture• Fitbit makes the Aria smart
scale• Scale syncs through home Wifi
to Fitbit cloud for display & analysis through web & native applications
• 3rd party services can access weight data to provide additional analysis
Security & privacy requirements• Confidentiality
• Integrity
• Authentication
• Transparency
• Intervenability
• Unlinkability
Security & privacy requirements• Confidentiality
• Integrity
• Authentication
• Transparency
• Intervenability
• Unlinkability
Confidentiality & Integrity
• Weight data must be secured both on servers & in-transit– Encryption & access control ensures
confidentiality on Fitbit & 3rd party servers– TLS ensures confidentiality in-transit– TLS protects against modifications in-transit
• Both OAuth & Connect mandate TLS for over-the-network messages
Security & privacy requirements• Confidentiality
• Integrity
• Authentication
• Transparency
• Intervenability
• Unlinkability
Native Application authentication• Users can view their weight
data & trends from Fitbit ioS & Android native applications
• Native apps pull data from Fitbit cloud REST endpoints
• Native applications can use OAuth to authenticate their API calls as being on behalf of particular user
3rd party application authentication• TrendWeight offers additional
insight & analysis of weight data
• Pulls weight data from Fitbit cloud REST endpoints
• TrendWeight uses OAuth to authenticate to Fitbit as acting on behalf of particular user
• The token represents the relationship between TrendWeight and that user
Cloud to Cloud
Copyright © 2014 Ping Identity Corp. All rights reserved.26
Login & consent
Weight data
Login & consent
Weight data
Access token delivery
Copyright © 2014 Ping Identity Corp. All rights reserved.28
• Devices communicate with each other and the gateway via the local network— sharing data, sending control messages, etc.
• These local interactions may not use HTTP, but instead a application protocol more optimized to the constraints (CPU size, battery, etc.) of devices.
• Such application protocols include XMPP, MQTT and CoAP.
• Work has begun in exploring how to bind OAuth & Connect to such IoT optimized protocols, e.g. ACE effort in IETF
Device authentication
Security & privacy requirements• Confidentiality
• Integrity
• Authentication
• Transparency
• Intervenability
• Unlinkability
Transparency• Users actively mediate
the issuance of tokens to native applications & 3rd parties
• Provides opportunity for an explicit consent step
• In theory can enable granular consent, ie view only weight data but not step data
Security & privacy requirements• Confidentiality
• Integrity
• Authentication
• Transparency
• Intervenability
• Unlinkability
Security & privacy requirements• Confidentiality
• Integrity
• Authentication
• Transparency
• Intervenability
• Unlinkability
Unlinkability
• Authenticating to Fitbit or sharing weight data to 3rd party services should not directly enable inappropriate correlation at some other party , eg Facebook
• Linkages must be explicit and consensual, as in that established between FitBit & TrendWeight