haystack + dash7 security
TRANSCRIPT
Haystack + DASH7 Security
1
Similarities & Differences of PHY/MAC
DASH7 DASH7/LoRa 6LoWPANPrimary Spectrum 433 MHz 433/915 MHz 2450 MHz
Supported Bitrates 26.5, 53, 106 kbps 1 - 26.5 kbps 250 kbps
Modulation/Encoding MSK / FEC+RS CSS / FEC MSK / DSSS
Network Model Host – Host Host – Host
Multiaccess ModelsCSMA-CA
Time slottingQuery Arbitration
CSMA-CATime slotting
MAC Data Integrity High Low
MAC Cryptography AES128 EAX AES128 CCM
Frame MTU 256 bytes 127 bytes2
Similarities & Differences of PHY/MAC
DASH7 DASH7/LoRa 6LoWPANPrimary Spectrum 433 MHz 433/915 MHz 2450 MHz
Supported Bitrates 26.5, 53, 106 kbps 1 - 26.5 kbps 250 kbps
Modulation/Encoding MSK / FEC+RS CSS / FEC MSK / DSSS
Network Model Host – Host Host – Host
Multiaccess ModelsCSMA-CA
Time slottingQuery Arbitration
CSMA-CATime slotting
MAC Data Integrity High Low
MAC Cryptography AES128 EAX AES128 CCM
Frame MTU 256 bytes 127 bytes
CRC validation of the frame is vulnerable to incorrect length byte in header.
Koopman & Chakravarty, CRC Polynomial Selection For Embedded Networks
EAX is a newer (2004) cipher for AES. ‣ Standard AES keys & distribution! ‣Runs twice as fast as CCM! ‣Can encrypt MAC addresses (CCM can’t)! ‣ Packets don’t need to be 16byte aligned!
2
Networking Strengths Weaknesses
• Fast, low-power network sync • Fast round-trip for request/response • Universal MAC precludes App Profiles • Supports core IPv6 features & UDP
• New, so few implementations available • Formal support for only 2 hops • No TCP support at present
• Possible to do almost all IPv6 features • Mature implementations available • Lots of PHY/MAC options
• App data really should use internal CRC! • No standard way for low-power network sync • Needs a lot of extra work up the stack and in
definition of application profiles
Greatest Differentiation is in Networking
DASH7
6LoWPAN
3
Networking Strengths Weaknesses
• Fast, low-power network sync • Fast round-trip for request/response • Universal MAC precludes App Profiles • Supports core IPv6 features & UDP
• New, so few implementations available • Formal support for only 2 hops • No TCP support at present
• Possible to do almost all IPv6 features • Mature implementations available • Lots of PHY/MAC options
• App data really should use internal CRC! • No standard way for low-power network sync • Needs a lot of extra work up the stack and in
definition of application profiles
Let’s Investigate a Few Areas
4
DASH7
6LoWPAN
802.15.4 CRC is Vulnerable
• On vulnerable MAC’s, payloads should have their own integrity check.
• Seminal research on the topic published only in 2012.Koopman & Chakravarty, CRC Polynomial Selection for Embedded Networks. 2012.Mirror: http://www.indigresso.com/wiki/doku.php?id=dash7_mode_2:crc_research
• Some polynomials we thought were good, are not.
• Length byte (header) must be protected independently. If frame length is wrong, the frame-CRC gets marginalized no matter how strong it is.
DASH7 LoRa HW Support 6LPCRC Poly CRC16-IBM CRC16-IBM CRC16-CCITT
Koopman’s Rating Strong Strong WeakHeader CRC Yes Yes No
5
Contrasting Methods of Network Sync To do it in a low-power way, network asymmetries must be exploited
DASH7 6LoWPAN
Idle Mode Background Detect Duty-cycled RX
Asymmetry Exploited Plug-in nodes can transmit streams
Plug-in nodes can transmit streams
Low-Power Listening Yes Yes
Provides Group Sync Yes No
Endpoints Stay Quiet Yes Yes
Sync Latency (typ) 1 - 2 sec 1 - 2 sec
On-time / Period (typ) 1.3 ms / 500 ms 8 ms / 1s6
Contrasting Methods of Network Sync To do it in a low-power way, network asymmetries must be exploited
DASH7 6LoWPAN
Idle Mode Background Detect Duty-cycled RX
Asymmetry Exploited Plug-in nodes can transmit streams
Plug-in nodes can transmit streams
Low-Power Listening Yes Yes
Provides Group Sync Yes No
Endpoints Stay Quiet Yes Yes
Sync Latency (typ) 1 - 2 sec 1 - 2 sec
On-time / Period (typ) 1.3 ms / 500 ms 8 ms / 1s
Typical figures: all standards can be configured to optimize latency vs. low power.
6
6LoWPA
N: R
epeat the Packet
• Idea is to send the request packet many times, so the receiver can “strobe” its listening cycle and still get the data.
• Many different — but similar — variants of above: BMAC, XMAC, BoXMAC, WiseMAC, ContikiMAC, … others
• Downside: synchronizes one endpoint at a time, not a group all at once.
• Downside: if data rate is low, packets are long & receiver listens a lot.
DD D A
AD
D
A Acknowledgement packet
Data packet
Reception window
Send data packets until ack received
Sender
Receiver
Transmission detected
D
Figure 1: ContikiMAC: nodes sleep most of the time andperiodically wake up to check for radio activity. If apacket transmission is detected, the receiver stays awaketo receive the next packet and sends a link layer acknowl-edgment. To send a packet, the sender repeatedly sendsthe same packet until a link layer acknowledgment is re-ceived.
Send data packets during entire period
Data packet
Reception windowSender
Receiver
Transmission detected
D
D
D DD D
D
D
Figure 2: Broadcast transmissions are sent with repeateddata packets for the full wake-up interval.
2 ContikiMAC
ContikiMAC is a radio duty cycling protocol that uses pe-riodical wake-ups to listen for packet transmissions fromneighbors. If a packet transmission is detected during awake-up, the receiver is kept on to be able to receive thepacket. When the packet is successfully received, thereceiver sends a link layer acknowledgment. To trans-mit a packet, a sender repeatedly sends its packet untilit receives a link layer acknowledgment from the receiver.Packets that are sent a broadcasts do not result in link-layer acknowledgments. Instead, the sender repeatedlysends the packet during the full wake-up interval to en-sure that all neighbors have received it. The principle ofContikiMAC is shown in Figure 1 and Figure 2.
CCA
td
Ack
Data packet Data packet
ti
ta
tc
tr
tr
Sender
Receiver
CCA
Figure 3: The ContikiMAC transmission and CCA tim-ing.
2.1 ContikiMAC Timing
ContikiMAC has a power-efficient wake-up mechanismthat relies on precise timing between transmissions. Con-tikiMAC wake-ups use an inexpensive Clear Channel As-sessment (CCA) mechanism that uses the Received SignalStrentgh Indicator (RSSI) of the radio transceiver to givean indication of radio activity on the channel. If the RSSIis below a given threshold, the CCA returns positive, in-dicating that the channel is clear. If the RSSI is above thethreshold, the CCA returns negative, indicating that thechannel is in use.
The ContikiMAC timing is shown in Figure 3. The tim-ing requirements from the figure are:
ti: the interval between each packet transmission.
tr: the time required for a stable RSSI, needed for a stableCCA indication.
tc: the interval between each CCA.
ta: the time between receiving a packet and sending theacknowledgment packet.
td: the time required for successfully detecting an ac-knowledgment from the receiver.
The timing must satisfy a number of constraints. First,ti, the interval between each packet transmission, must besmaller than tc, the interval between each CCA. This isto ensure that either the first or the second CCA is ableto see the packet transmission. If tc would be smallerthan ti, two CCAs would not be able to reliably detect atransmission.
The requirement on ti and tc also place a requirementon the shortest packet size that ContikiMAC can support,
2
Example is of “ContikiMAC”http://www.dunkels.com/adam/
dunkels11contikimac.pdf
7
DA
SH7: A
dvertise & G
roup Sync
ETA500
Info0
ETA1
Info0
ETA0
Info0
Foreground RequestBackground AdvertisingBackground AdvertisingBackground Advertising
Host A sends a stream of special “background frames” containing Advertising Protocol Data. The data includes the time when the
next request will occur (e.g. 500 ms).
Host A sends synchronized request
at planned time
Any number of other Hosts can listen for advertising. 1. Briefly sample the channel for any activity. 2. Check for signs that it’s a background frame (part of design). 3. Receive the background frame.
1 2 3
All listeners can receive request, all can send
responses, all are now synced to each other.
DASH7’s advertising & synchronization model follows from the previous concepts. It provides group synchronization, allows for wide
tolerances in device specs, and also scales to low data rates.
8
Low-Pwr Advertising & Group Sync Timeline
Engineers have pursued low-power advertising for years. The goals have been mostly consistent: ‣ Minimize RX on-time ‣ Minimize False-positives ‣ Maximize True-positives
DASH7’s method is the first to use a bifurcated frame specification and real-time synchronization units (ms). 20 years of collective R&D, but the concept finally works and scales.
1990
’s20
00-2
010
2010
—
Transmission of long preamble ahead of request packet.
BMAC proposed (early 2000’s): A protocol using countdown packets.
ISO 18000-7.1 (early 2000’s) structured long preamble
TinyOS group implements BMAC+: struggles, finds impractical (late 2000’s)
Final spec of DASH7 MAC and Advertising Protocol (2012)
9
Fast Group Sync Enables Fast Round-Trip Synchronize devices, send request, and get responses before endpoints are GONE
“Chaotic” Conditions assume: ‣ Endpoints as well as internet gateways
(i.e. edge routers) may be mobile. ‣ “Potpourri of ownership” of the
endpoints & gateways.
Some examples of chaotic networks: ‣ Getting sensor data off-of tags in a
moving vehicle (see diagram). ‣ Smartphones querying smart objects
and each other.
30 m
/s
Advertising (1s)
Request (<50ms)
Responses (1s)
Discovering and getting data from low-power devices inside a vehicle going highway speed is a hard problem, but it is one for which DASH7 is well-suited.
Any IP address
WAN
/4G
DASH7Gateway
10
Networking Strengths Weaknesses
• Fast, low-power network sync • Fast round-trip for request/response • Universal MAC precludes App Profiles • Supports core IPv6 features & UDP
• New, so few implementations available • Formal support for only 2 hops • No TCP support at present
• Possible to do almost all IPv6 features • Mature implementations available • Lots of PHY/MAC options
• App data really should use internal CRC! • No standard way for low-power network sync • Needs a lot of extra work up the stack and in
definition of application profiles
Let’s Investigate a Few Areas (Update)
DASH7
6LoWPAN
11
Implementing Trivial AppsDASH7 stacks have built-in application functionality
DASH7
PHY/MAC/NET
Sessioning
Transport Layer
Applications
Filesystem
Transport Layer Apps (TLA’s) include: ‣ Beaconing Series (a.k.a. “Announcement”) ‣ Inventory & Collection Queries
User configures TLA’s and provides them with data via Filesystem API.
12
What Exactly is the DASH7 Filesystem? A consistent data model & API to promote multi-app, multi-vendor interoperability
DASH7
PHY/MAC/NET
Sessioning
Transport Layer
Applications
Filesystem
• L6, queryable, database-ish API
• root/admin/guest XRW privileges
• Up to 256 “BLOB” files (Generic Files)
• Up to 1024 indexed short files (ISF’s) ‣ Low-level (L4) queries happen here ‣ Batch or single-file access ‣ 0-15 used as configuration registry ‣ Rest available to user for arbitrary data
storage, application ports, etc.13
What Exactly is the DASH7 Filesystem? A consistent data model & API to promote multi-app, multi-vendor interoperability
DASH7
PHY/MAC/NET
Sessioning
Transport Layer
Applications
Filesystem
• L6, queryable, database-ish API
• root/admin/guest XRW privileges
• Up to 256 “BLOB” files (Generic Files)
• Up to 1024 indexed short files (ISF’s) ‣ Low-level (L4) queries happen here ‣ Batch or single-file access ‣ 0-15 used as configuration registry ‣ Rest available to user for arbitrary data
storage, application ports, etc.
Filesystem is key to security and interoperability of binary data formats.
13
Why D
ASH
7 Filesystem M
atters
Alice’s Network
Bob’s Network
DASH7 Endpoint with default configuration.
Alice discovers Endpoint & uploads network params
Endpoint leaves Alice, joins Bob. Bob uploads its network params
A DASH7 device can productively carry data across diverse IoT networks. Today’s IoT lacks such a distributed data model, and as a result data gets stuck in cloud “silos.” On the other hand, a distributed data model promotes IoT market growth and market-wide commitment to data security features.
14
Why D
ASH
7 Filesystem M
atters
Alice’s Network
Bob’s Network
DASH7 Endpoint with default configuration.
Alice discovers Endpoint & uploads network params
Endpoint leaves Alice, joins Bob. Bob uploads its network params
A DASH7 device can productively carry data across diverse IoT networks. Today’s IoT lacks such a distributed data model, and as a result data gets stuck in cloud “silos.” On the other hand, a distributed data model promotes IoT market growth and market-wide commitment to data security features.
Not to mention, the potential to spider & search an open IoT.
14
