design and implementation of a 3-party cloud-backed handshake for secure grouping of wifi iot...

#p2pwifi #groupconnect #IoT#handshake #cloudappsDesign and Implementation

[email protected]/06/22@RCS研@石垣島

PDF: bit.do/170622

Zhanikeev Marat

of a 3-Party Cloud-Backed Handshakefor Secure Grouping of WiFi IoT Devices

M2M, D2D in 4G+ Networks

SC

BS

SC SC

Marat Zhanikeev – [email protected] Design and Implementation of a 3-Party Cloud-Backed Handshake for Secure Grouping of WiFi IoT Devices 2/142/14

..and the much wanted OFFLOAD• simply put, use device-to-cloud connections as little as possible• reality: BeaconStuffing is not available, P2P WiFi (=WiFi Direct, Miracast) almost there,SSID is fully accessible

• this paper: focus on the 3-party handshake with the help of SSIDbeaconing

WiFi

3GConnectivity

WebAppCloud

Newparadigm

BeaconStuffing


Use 32 octets in SSID wisely


The Unit Handshake Process

CloudClient A Client B

id,GPS,APs

Seeking group!

Check -inHashkeyHashkey

>> SSID

Groupingrequest

Matching

Check-inB’s hashkey

Hashkey>> SSID

Direct comm.

• given: IoT devices use periodicpolling to sync with cloud side

• efficiency: stay withing pollingrequests as much as possible

• hashkeys are always generated andmaintained by cloud side

• devices provide feedback on localenvironment for the cloud side to sort(matching)


Modeling for Trace-Based Analysis• it takes about 3-5s to reconfigure and start WiFi Hotspot, plus lazybeaconing for energy efficiency

• note: SSID messaging is quick while WiFi Direct contact will requireadditional overhead

Cloud API

Client A

Effectiverange

Walking path

Lazy BeaconingWiFi DirectGroupingDiscovery

Client B

Local traffic


Modeling Wireless Encounters

0 1 2 3 4 5 6 7 8 9Time order

20406080

100120140160180200

dist

ance

0 1 2 3 4 5 6 7 8 9Time order

0

0.2

0.4

0.6

0.8

1

spee

d

• used Statefair (matsuri?)

trace from Crawdad

• randomly extracted 1000encounters (meets)

• analysis target: see how manyencounters passrequirements as theygradually become stricter

• requirements: keep withina given distance for a givenlength of time


Performance Map

3 5 10 15 30 60 90 180

5

7

10

15

20

25

50

03 01 00 00 00 00 00 00

05 04 01 01 01 00 00 00

10 08 06 04 03 01 00 00

20 18 14 11 09 03 02 00

26 25 22 20 16 06 03 01

32 31 30 27 23 12 07 02

55 53 51 50 48 41 33 12

Effe

ctiv

e ra

nge

(met

ers)

Session duration (seconds)

• only 55% pass the lowestthresholds – too muchcontinuous motion at theStatefair

• above 20% is probablyacceptable for deployment oflocal wireless app

• cells like 30s/20m, 10s/15m should be OK in practice


Practice/Implementation

• already have working prototypes on Android below 6.0◦ since 6.0, runtime permission and other major changes make it much harder (not

impossible, though) to write such apps◦ so, basically, voice in favor of Android-based IoT devices, fog clouds, etc.

• implementing SSID beaconing is very easy, but Beacon Frame is notaccessible (shame!)

• next step: add WiFi Direct for a full-scale localized wireless IoT device withhigh throughput◦ high throughput is a tentative step towards olympics (current plans will definitly not be

able to handle the load come 2020)◦ ... like local video streaming...


That’s all, thank you ...


Extras: An IoT Fog Box

• prototype uses Local Hardware Awareness (LHAP) and WiFi Direct onRaspberry Pi

WiFi

Wireless users

WiFi AP

Physical Device

Cloud Platform

VM VM Con. Con. Con.

Storage

Sensors

…

Beacon

WiFi AP WiFi Client

P2P WiFi

Box’s


Theory Behind Local Grouping

To 3G/LTE

Virtual Wireless User

Internal Engine

To 3G/LTE

Resource Virtualization


Vehicular Groups as wireless offload

4~5G

Vehicular Group

4~5G End Users

Data Center (DC)


Running cloud apps on vehicles

Cars

Rarely Meet

Meeting Likely

Travel Together

Park Together

DTN MANETs

Traditional SingleConnect

Sensor Cloud

Storage Cloud

Information Support


design and implementation of a 3-party cloud-backed handshake for secure grouping of wifi iot...

Technology