T2TRG Breakout B 2015-10-31
-
Security considerations (see below)
- Contributors: Sandeep, Mohit, J, Oliver
- Problems and guidelines
- Disclaim completeness, focus on main message
- Appendices to possibly capture additional points
- Disclaim completeness, focus on main message
- Terms beyond RFC4949
- Terms to avoid
- Key management
- End-to-end security
- Terms to avoid
- draft-garcia
- cover whole lifecycle, avoid "media breaks"
- Everything security, including ACE
- SF's comments
- 1 Firmware update
- Recovery from errors
- Protection of incremental updates
- Trust issues in updated devices (posture)
- Firmware update as a significant lifecycle event
- Owner-initiated vs. vendor-initiated (maybe still owner-confirmed) update
- Coping with loss-of-service during update
- Distribution of updates
- Assembling updates from several sources (vs. "app-store")
- 2 Keeping the user in control, visibility/monitoring
- Plausible deniability as a vendor objective
- Visibility of bootstrapping transactions, operational exchanges
- 3 Avoiding device fingerprinting (or any permanent identifiers)
- Reduce linkability by using opaque, directed identifiers
- 4 transitions in the vendor role
- 5 Availability problems (DoS, e.g. as a byproduct of penetration testing)
- Posture!
- 1 Firmware update
- Handing over device ownership
- Previous owner retains access to historic data linked to device
- Data in the cloud
- Data in the device???
- Hierarchical ownership
- Hotel room scenario
- Non-voluntary transfer of ownership
- Device stolen, lost
- Bankruptcy
- De-commissioning, offboarding
- Previous owner retains access to historic data linked to device
- Lawful access
- Forensic readiness (and third-party verifiability)
- Regulation, Compliance
- Vendor role, OS provider, app-store provider, OEMs, ODMs, ...
- Lifecycle aspects here as well
- Cross-domain operation (e.g., between cars)
- Proximity vs. connectivity
- Owners vs. stakeholders, multi-tenant, ...
- per device, as a system
- accountability
- Security as a pre-requisite to safety
-
Survey Security Bootstrapping Approaches
- Contributors: Mohit, Carsten, Yizhou, Robert
- List solutions, reference draft-garcia
- Everything security but not covered by ACE
- Application security vs. network security
- Network bootstrapping as a byproduct of application bootstrapping
- Discuss in the context of general pre-operational flows
- Set in context of, relate to maintenance, ownership transitions
- Terms beyond sec.cons. and RFC4949
- pre-operational setup, including discovery
- draft-he
- possibly solutions documents (6tisch, 6lo, anima), 802.1AR
- find "hidden gems" (documents that we want to point to that aren't explicitly about bootstrapping)
- often: small windows of vulnerability -- acceptability of limited opportunity to exploit (leap of faith/TOFU)
- Usability aspects ("zero-touch" etc.)
- Per-solution characteristics
- Assumptions/Prerequisites
- e.g., manufactured with key
- out-of-band channels (QR-code, buttons)
- usability aspects, user actions required
- what is provisioned (network, application; PK vs. SK and how is that used)
- bundles, bundling process, bootstrap a bundle
- interfaces to shopping systems
- peer-to-peer vs. infrastructure-based
- Registration, authentication of human users (and cats)
- Rebootstrapping, ownership handover
- Assumptions/Prerequisites
- Grouping of solutions? What are the categories?
- Oliver reports from W3C IG IoT breakout session
- Consensus on landscape of security & privacy means
- Extensive toolset available for security & privacy
- These tools will not be sufficient, need new tools
- same structure, but maybe shrink it for IoT
- new structure
- Most (not all) of these mechanisms need to be standard mechanisms
- Distributed systems: lots of prior art; five disciplines:
- Privacy
- Authorization
- Authentication
- Secure communications and storage
- Provisioning and credentialing
- Specific WoT needs:
- Physical goods (in additional to digital goods)
- Constrained devices
- Constrained networks
- Not only human users
- Not only IT applications
- Connectivity, de-perimeterization
- Technology generations
- Classic (Kerberos, SAML, TLS, ...)
- New (OAuth, FIDO, ...)
- Future
- Standardized vs. DIY
- In the web: only TLS is really standardized (OAuth is a zoo)
- Consensus on landscape of security & privacy means
Mohit: When? Oliver: Want draft version by end of January dsr: Chartered as work items Oliver: Wikis are public... You can read... dsr: Moving to a github document
https://www.w3.org/WoT/IG/wiki -> https://www.w3.org/WoT/IG/wiki/Security,_Privacy_and_Resilience -> https://www.w3.org/WoT/IG/wiki/Landscape_of_Security%26Privacy_Means -> https://www.w3.org/WoT/IG/wiki/Design-Time_Security%26Privacy_Means
Will do more privacy and resilience later
How to contribute: -- review of the github book (to be created in 4-5 weeks), issue tracker -- sending e-mail, comments to be integrated by Oliver -- can invite people to the bi-weekly Webex calls, dialling details on the Wiki page... (Technically speaking, you need to be a W3C member or an invited expert).
IIC security call...
New W3C WGs: -- strong authentication (as in FIDO) -- hardware-based security Relationship to web security model (Also relevant for Apple-Pay-like security)
Freshness
-- DTLS (replay protection) does not guard against delay attacks...
-- limited validity time of authorized commands...
Most IoT devices don't have wallclock time
4-way handshake 1st exchange: get a token 2nd exchange: use that token server provides limited lifetime to that token
-- local clocks on client and server -- guarantee some maximum clock skew
1st exchange: get a token and a clock value (may be provided as part of some other exchange)
.... 2nd exchange: client updates the clock value .... another 2nd exchange: client updates the clock value again
this works for as long as: maximum vulnerability window / clock skew rate
[token, clock value] (needs protection) May not need to standardize anything beyond this data structure
-- Application requirement -- integrate it into protocols -- at which layer? "do not put burden on ordinary developers"
Add mostly-offline nodes (and challenged channels)
#############################################################################
(An example to be used for the bootstrapping survey document.)
Multicast useful for lighting -- no popcorn effect
Compress IPv6 addresses into one byte
| Cloud | GW | Thing | |-------+----+-----------------------------------------------------------------| | | | <- multicast to all network controllers | | | | device desc (SGTIN -- global trade item number + serial number) | | | | (has its own key pair, PK in the cloud, service to include PK) |
- GW -> Thing "get public key", device returns raw PK (RSA2048, openssl format)
(authorization for the following key transfer requires user involvement or cloud involvement)
- GW sends over network key, encrypted with AES-one-time key, plus AES one-time key (RSA weakness -- same data with different PK)
(GW generates new network key on factory reset...) [RF; noise is good]
Alternative (Manufacturer might want to blacklist devices): Get PK from cloud
No mutual authentication Could be your neighbor's gateway (christmas effect), need bundling
Device description says whether cloud-based or user-based onboarding is desired (RWE devices don't have user-based)
(There is a shared-secret variant)
80 MHz Cortex-M3, 3.5 s to decrypt RSA-encrypted network key
Inclusion and exclusion each generate factory-reset of the device.
Mohit: looks similar to EAP...
Mohit: "Blacklisting is broken": Cloud can blacklist devices, but if the device description can control whether cloud is used, that is broken. Daniel: If the thing does not have the PK service, and it is stolen, it is no longer useful... (Device has a "secret public key")
[Daniel: IPR disclosure: Shared-key version of this plausible deniability approach is patented]
| Cloud - GW | GW - Thing | | | < ID | | < ID + ENC_one(net) | | | ENC_dev(ENC_one(net)) > | | | | ENC_dev(ENC_one(net)) + one > | | | |
E.g., Zigbee's PANA + EAP-TLS for network keying (admission) -- widely tested
Authentication transport protocol, e.g., need relay from link-local address
Network security vs. Application Security Pre-operational vs. Operational Security
For the Jan 2016 plugfest, focus on Operational Application Security
- simple to add the DTLS protection
- focus on authorization, not authentication
Use the security token to decide access cf. draft-bormann-core-ace-aif-03.txt (AIF = authorization for a single entity; a policy would include this information for multiple entities)
Open up a menu of "entrances" with or without some of this functionality (for testing, not for production)
Mechanism in place, define policy appropriate for the various stages of testing.
How to associate AIF with a specific access? (In HTTP; this would be a RFC6750 bearer token in the HTTP "Authorization" header field, as in: Authorization: Bearer mF_9.B5f-4.1JqM Maybe just put the AIF in the equivalent CoAP option, unless the DTLS connection already provides the AIF.)
Writing code: Carsten, Dave, Daniel?, Oliver, Robert??? Baseline: IP over anything
W3C side: Johannes + Oliver will present to IG on [Dave will find out]. Slideware to be provided for that.
- keywords for long-term definition of the charter: understand and evaluate IoT security survey find problems evaluate proposals for solutions reference scenarios gap analysis
(do not write into the charter things like:
-
what is different in IoT )
-
current set of milestones (initial focus)
- the two documents (sec. cons. and bootstrap survey)
- plugfest contribution
Carsten to send draft slides for the Breakout B report to t2trg@irtf.org tomorrow