Internet of Things (IoT) · Internet of Things (IoT) WLAN Design, Security and Administration...

Internet of Things (IoT) WLAN Design, Security and Administration Challenges

WLAN Professionals Conference Berlin - October/2015

© Aerohive Networks, Proprietary & Confidential


Overview

2

• Introduction

• Consumerization of IT

• History of Wi-Fi client devices

• IoT WLAN design considerations

• IoT management considerations

• IoT security considerations

David Coleman Senior Mobility Leader - Aerohive Networks

CWNE #4

@mistermultipath

Who am I?

Sybex CWNA Study Guide 4th Edition

ISBN: 978-1119067764

Who am I?

Co-author of:

http://amzn.com/1119067766

Coming Soon:

Sybex CWSP Study Guide 2nd Edition ISBN: 978-1119211082

Amazon preorder:


Who am I?




Internet of Things (IoT)

© Aerohive Networks, Proprietary & Confidential 6

• Technology research firm Gartner estimates that by 2020, the number of Internet of Thing (IoT) devices will be 26 billion units worldwide, which far

exceeds the expected 7.3 billion PCs, tablets, and smartphones.

• Could this be the beginning of the self-aware Skynet predicted by the Terminator movies?

Internet of Things (IoT)


New enterprise WLAN challenges lie ahead in a world where all the number of IoT devices far exceeds the number of people on the planet Earth.

WLAN administrators will have to confront new WLAN design, security and administration challenges as we move into the future with an IoT connected

world.

Consumerization of IT


• Consumerization of IT is a catch-phrase

used to describe a shift in information

technology (IT) that begins in the

consumer market and moves into

business and government facilities.

• Employees introduce consumer market

devices into the workplace after already

embracing new technology at home.

• Evil Rogue APs forced the enterprise to

deal with Wi-Fi

History of enterprise Wi-Fi client devices


• In the beginning there was scan guns

• Then came the laptops

• Then came smart phones and tablets

• Wearable devices*

• IoT devices*



• Personal mobile Wi-Fi devices, such as smartphones

and tablets, have been around for quite a few

years.

• The Apple iPhone was first introduced in June 2007.

• Apple iPad debuted in April 2010.

• HTC introduced the first Android smartphone in

October 2008.

• Smart phones and tablets now exceed laptop

connectivity in the enterprise.



• Holder

• Holder

IOT WLAN DESIGN


2.4 GHz


• 2.4 GHz is a disaster zone

• Only three usable channels

• Almost impossible to prevent CCI

• High SNR

• Oversaturation of 802.11 devices

• Non-802.11 transmitter interference

5 GHz is the answer


Dynamic Frequency Selection

U-NII-2A

38 46 54 62

U-NII-1 U-NII-2C U-NII-3 U-NII-4

102 110 118 126 134 142 151 159

42 58 106 122 138 155

50 114

70 78 86 94

74 90

82

U-NII-2B

36

40

44

48

52

56

60

64

100

104

108

112

116

120

124

128

132

136

140

144

149

153

157

161

165

173

177

181

169

68

72

76

80

84

88

92

96

5.15 5.25 5.35 5.47 5.725 5.925 5.825

5.85

167 175

171

163

Take the Pledge


• Do not deploy 802.11

radios that transmit

exclusively on 2.4 GHz.

• This pledge should be for

all 802.11 devices, not just

IoT devices.

• Ensure that the 5 GHz

radios support DFS

channels.

• Sadly…. Most IoT radios

are currently only 2.4 GHz

#takethepledge

Airtime Consumption


• Cheap IoT radios that only support 802.11b data rates are still

going to slow everyone down

• May only support data rates of 1 and 2 Mbps

“Where we are going, we don’t need 802.11b”

IoT and Multipath


• IoT devices may use non-MIMO

chipsets

• Multipath becomes our enemy

once again

• High multipath environments can still

have an impact on non-MIMO

clients such as IoT sensors

IoT and Multipath


• Bad news: Most IoT clients are non-

MIMO.

• Bad news: Non-MIMO IoT clients will

still be negatively impacted when

receiving downstream traffic from

the APs.

• Good news: MIMO APs support

maximum ratio combining (MRC)

• Most communication from IoT

sensors is upstream to the AP and

MRC compensates for multipath.

IoT and Design


• Do we redesign the WLAN to cut down

on reflections and multipath?

• Life will be better if the IoT devices use

1x1:1 MIMO radios supporting both

maximum ratio combining (MRC) and

space time block coding (STBC).

• Example: Adriano 1x1:1 b/g/n

www.arduino.cc

https://www.arduino.cc

IoT and MU-MIMO

21

IoT and MU-MIMO

22

• Requires clients to have

802.11ac chipset that

supports explicit transmit

beamforming.

• IoT client support for TxBF is

currently not a reality.

• Clients need to be medium

range from the AP

• Clients must have distance

between each other

• Downstream only

IoT and MU-MIMO

23

• Might be a good fit for IoT

devices that are bandwidth

intensive.

• Reduction in airtime

consumption for downstream

transmissions.

• Not a reality at this point.

IoT and IPv6


• Everything has an IP address

• Multiple LLC… 802.3, 802.11, etc

Management & Monitoring


• Bring Your Own Device (BYOD)

• Although mobile devices initially were

intended for personal use, employees

now want to use their personal mobile

devices in the workplace.

• Employees have expectations of

being able to connect to a corporate

WLAN with multiple personal mobile

devices.

• We live in a BYOD world

CORPORATE ISSUED

LAPTOP

PERSONAL

CONSUMER TABLET

CORPORATE ISSUED

SMARTPHONE

CORPORATE ISSUED

TABLET

PERSONAL SMARTPHONE

BYOD

• Mobile Device Management (MDM)

• MDM solution might be needed for

onboarding personal mobile devices as

well as corporate issued devices

• Corporate IT departments can deploy

MDM to manage, secure, and monitor

the mobile devices

MDM

• Mobile Device Management (MDM)

• Secure over-the-air provisioning of

MDM profiles - Device restrictions

• Easy way to distribute root CA

certificates for 802.1X security with

mobile devices

• Over-The-Air Management

• Application Management

MDM

• Onboarding solutions for

mobile devices may the better

way to go

• Simple way to distribute and

install certificates or PPSK

security credentials to mobile

devices

• Installation process should be

simple and painless for the

end user

All aboard!

IoT Management


• MDM is not intended for IoT devices

• MDM solutions are based on Google and Apple APIs

• We will need management solutions because…

• We are beginning to live in an IoT world

• Currently consumer driven, but moving to the

enterprise

IoT Framework

Physical Device (sensing, monitoring, actuation, control…)

Communication

Services (monitoring, data publishing,

discovery…)

Application (interface to the user)

Security (authentication

, authorization,

data

integrity…)

Management

IoT Communication

• The application functional block usually resides somewhere in the cloud.

• The communication with the Cloud is often done through RESTFul APIs, which use HTTP for transport.

Application (interface to the user)

https://en.wikipedia.org/wiki/Representational_state_transfer

API Overview - External


HiveManger NG

NG GUI External API

(monitoring, location, utility…)

Partner App #2

Partner App #3

REST API call

Partner App #1

• Aerohive provides an external RESTFul API that may be used by customers,

partners, and managed service providers to integrate with Aerohive

services.

• The Monitoring API exposes information related to a customer's access

points and client devices connected to APs.

https://en.wikipedia.org/wiki/Representational_state_transfer

Big Data


• Big data is a broad term for data sets so large that traditional data processioning applications are insufficient.

• Data collection grows in size in proportion to the numerous low-cost and low-power IoT devices.

• Predictive analysis derived from big data sets. • Applications and APIs will be vital.

IOT WLAN SECURITY


IoT and WLAN Security


• The 802.11-2012 standard defines

authentication and key management

(AKM) services.

• Authentication required for key creation

• Robust Security Network (RSN) dynamic

encryption

• 4-Way Handshake

Supplicant

PMK

PTK created

PTK created

GTK created

GTK delivered

GTK

Temporal keys installed

Controlled port unblocked

EAPOL-KEY message #1




PTK

Master Keys: PMK and GMK

Temporal Keys: PTK and GTK

PMK GMK

Authenticator

GTK

Temporal keys installed

PTK

Validating Identity is important

• David Coleman

• Wi-Fi Geek

• Born February

1960

• David Coleman Headley

• Convicted terrorist

• Born June1960

LDAP

EAP EAP

RADIUS CLIENT AP

Root CA cert Server cert

802.1X/EAP

• Extensible Authentication

Protocol (EAP)

• Server certificate and Root

CA certificate

• Tunneled authentication using

SSL/TLS

• 802.1X: Port based access control

• Authorization Framework

• Supplicant

• Authenticator

• Authentication Server

• Integrates with LDAP

LDAP

EAP EAP

RADIUS CLIENT AP

Root CA cert Server cert

802.1X/EAP

• Most secure authentication method

• Ideal for the enterprise

• Certificates and PKI needed

• Can be difficult to deploy

• Can be difficult to troubleshoot

• Not necessarily ideal for IoT devices

PSK


PSK =

Password123!

PSK =

Password123!

• 8-63 character shared

passphrase

• Never intended for use in the

enterprise

• Susceptible to offline dictionary

attacks

• Wi-Fi Alliance recommends 20

strong characters or more

• Biggest weakness is that the PSK

credential is “static”

PPSK


• Several WLAN vendors offer

proprietary PSK solutions

• Multiple per-user and per-

device PSKs assigned to a single

SSID

• Easy to deploy

• Can be time-based credentials

• Solves the “static” PSK problem

• 802.1X not always an option

• PPSK provides unique per-device secure credentials

• PPSK provides deployment simplicity

• PPSK scales

IoT device security

^F/Lf&K&,2Em{h^w

4QYu[PE_~qeXKa"D

u2sy5)X@>+<Zd2}H

~g{{HdyjkJ+_Kk8M M%y72V&=A~.E]wJE

k$a=8;7Lz9@~K7$%

IoT security demo


Marko Tisler International Technical Training

CWNE #136

@tishlaaar

TDLS


Access Point

TPK

TDLS

responder

STA

TPK

Direct Link

TDLS

initiator

STA

• Tunneled Direct Link Setup (TDLS)

• Future replacement for PSK

authentication

• Secure Authentication of Equals

(SAE)

• SAE is a variant of Dragonfly, a

password authentication key

exchange based on a zero-

knowledge proof

SAE commit

SAE commit

SAE confirm

SAE confirm

Select

passphrase Select

passphrase

Future Security

• Prove you know the credentials

without compromising the

credentials

• No forging, modification or

replay attacks

• No offline dictionary attacks

SAE commit

SAE commit

SAE confirm

SAE confirm

Select

passphrase Select

passphrase

Future Security

• Two authentication

message exchanges:

• commitment exchange

used to guess password

• confirmation exchange

to prove password was

guessed correctly

• PMK is then derived

• 4-Way Handshake

SAE commit

SAE commit

SAE confirm

SAE confirm

Select

passphrase Select

passphrase

Future Security

802.11ah


• New MAC and PHY

• Operates below 1 GHz: 900-928 MHz USA | 863-868 MHz Europe

• Ideal for low power consumption and long-range data transmissions

• Ideal for machine-2-machine communications such as sensor

networks

• Mandatory: 1 mHz and 2 mHz modes - Support: 4, 8 and 16 MHz

• Up to 8,191 devices associated with an access point (AP) through a

hierarchical identifier structure

• Low power consumption due to short and infrequent data

transmission and targeted wake-up times

• Data packet size approximately 100 bytes

• 150 Kbps minimum data rate


Questions

49


Response

50

Next three slides are a quick response to an opposing view that was presented during the convention:

• Agree that IoT is not only a Wi-Fi technology. IoT devices will operate using

other RF technologies such as Zigbee, Bluetooth and more.

• IoT devices will operate at many MAC layers and the their underlying

physical layer.

• Agree that IoT needs to operate on other frequencies which is why this

presentation also mentioned the 802.11h amendment and below 1 MHz

frequencies.

• Disagree that Wi-Fi IoT devices should remain on 2.4 GHz and never

transmit on 5 GHz. Currently the majority of IoT radios are 2.4 GHz only, but

that will change and should change.


Response

51

Agree that there are many security challenges ahead. However, that is not a reason to discourage Wi-Fi IoT devices.

• Anything can be hacked. Human beings are always the weakest link.

• The Wi-Kettle hack was an application hack not an 802.11 security

hack

• Other technologies such as Bluetooth and Zigbee might also be

hacked

• The answer is to deal with security issues and not put our head in the

sand.


Response

52

Agree that there are many security challenges ahead. However, that is not

a reason to discourage Wi-Fi IoT devices.

• A strong 63 character unique passphrase that might protect an IoT device

such as a NEST thermostat is converted into a 256-bit PSK.

• A strong 63 character unique passphrase contains 170 bits of entropy

randomness and would take 100’s of years to crack with a brute-force

dictionary attack.

• Regardless, SAE is a proposed improvement for PSK/PPSK security

• As mentioned in this presentation, another issue is the security

management and administration of IOT devices. On-boarding solutions

for security credentials will have to be developed.

Thank you


Internet of Things (IoT) · Internet of Things (IoT) WLAN Design, Security and Administration...

Documents

Transcript of Internet of Things (IoT) · Internet of Things (IoT) WLAN Design, Security and Administration...