IOTECURITY & PRIVACY PERSPECTIVE —S

IOT —SECURITY & PRIVACY PERSPECTIVE

Parameswaran ThangavelPrincipal EngineerEMC

2015 EMC Proven Professional Knowledge Sharing 2

Table of Contents

Introduction ................................................................................................................................ 4

Section 1: IoT Basics ................................................................................................................. 5

What it is ................................................................................................................................ 5

Why now ................................................................................................................................ 6

IoT Elements .......................................................................................................................... 7

Nodes or Thing ................................................................................................................... 7

Gateway / Base Stations ..................................................................................................... 7

Backend service.................................................................................................................. 7

IoT Lifecycle ........................................................................................................................... 8

Bootstrapping ...................................................................................................................... 8

Operational ......................................................................................................................... 9

Maintenance & Re-bootstrapping ........................................................................................ 9

Decommission .................................................................................................................... 9

Section 2: Technology Stack .....................................................................................................10

Protocol Stack .......................................................................................................................10

6LoWPAN ..........................................................................................................................10

IPv6 ...................................................................................................................................10

CoAP .................................................................................................................................11

RPL ....................................................................................................................................12

MQTT ................................................................................................................................12

Section 3: Security Aspects.......................................................................................................12

Challenges ............................................................................................................................12

Bootstrapping .....................................................................................................................12

Operational ........................................................................................................................14

Maintenance & Re-bootstrapping .......................................................................................16

Decommission ...................................................................................................................16


Mitigations .............................................................................................................................16

Manufacture .......................................................................................................................16

Resilience to common attacks ............................................................................................17

Security Standards .............................................................................................................17

Complexity of the system ...................................................................................................18

System Monitoring .............................................................................................................18

Privacy Enhancing Technologies .......................................................................................18

Section 4: Adoption of IoT .........................................................................................................19

Adoption in India ....................................................................................................................19

Conclusion ................................................................................................................................20

References ...............................................................................................................................21

Disclaimer: The views, processes or methodologies published in this article are those of the

author. They do not necessarily reflect EMC Corporation’s views, processes or methodologies.


Introduction

Internet of Things (IoT), coined by Kevin Ashton in 1999, refers to identifiable objects and their

virtual representation in an Internet-like structure. Simply, IoT is a web of “things” that

communicate with each other constantly by exchanging data and with the provision to receive

commands from a remote system to be controlled. Things can be anything; a physical object

surrounding us or an object which we use in day-to-day activities. For a thing to become

communicable it needs to have computational power and communication capability. Once the

things start communicating with each other and exchange data, the data become the key for

next level of business opportunities.

Metcalfe’s Law states that the value of a telecommunications network is proportional to the

square of the number of connected users of the system (n2). The law was originally presented

in terms of “compatible communicating devices” rather than users. This law is very applicable

today and acts as a basis to see the value and the need for IoT.

A typical connected device (Machine-to-Machine) solution rely on point-to-point connections

with a PLC (programmable logic controller) module that rely on a proprietary protocol for

communicating with each other over either cellular or wired networks for automating the

industrial process. There are many M2M networks available today but they all act in silos and

communicate only within themselves and do not share data and are not capable to

communicate with the outside world or other consumer devices. With the advent of cloud

computing and big data analytics a potential value has been identified in connecting these silos

of M2M networks which will improve the business value.

IoT can be defined as a process of enabling existing M2M networks (or any device) to

communicate over the IP-based network (or internet) to share their data or state with the cloud

services and allow them to be controlled from other devices or users based on the action

determined due to the analytics performed on the data gathered from other M2M networks or

devices. Advances in technologies such as Embedded (or miniaturization) computing, Sensory

system, and Network & Communication systems have created more traction for IoT today.

There are a number of concerns and challenges when adapting to IoT. A few of them are power

consumption of the device, available CPU, network availability, scalability, manageability, and

Security and Privacy, Of all these, Security & Privacy is a key concern. Successfully addressing


the security and privacy concerns will drive the adaptability of IoT. Conversely, compromised

security and privacy could lead to causality of human life, not just financial loss.

This article explores the basics of IoT, various components that forms an IoT ecosystem,

protocol stack involved in an IoT, deployment patterns, and security and privacy concerns. The

article is divided into 4 sections. Section 1 covers the basics of IoT from its evolution,

components that constitute IoT, and the lifecycle of a device or thing in an IoT system. In

Section 2, we discuss various protocols (MQTT, CoAP, RPL, 6LoWPAN) that form an IoT stack.

Section 3 focuses on challenges in an IoT ecosystem from a security and privacy perspective,

as well as threat factors and possible mitigations for an IoT system. In Section 4, we examine

the current work on the various standards and a few initiatives and adaption of IoT in India. The

article concludes with a look at IoT in its current state and next steps.

Section 1: IoT Basics

What it is

In simple terms, Internet of Things (IoT) is defined as a collection of identifiable things (or

nodes) with the ability to communicate (send and receive commands) over wired or wireless

communication medium.

Machine to Machine (M2M) technology shares the definition defined above. However, M2M is

limited to interacting with the same types of devices, resulting in silos of different M2M

environments. Having those devices communicate over internet (IP based) enables realization

of the value of having those environments accessible remotely.

Enabling technologies such as Radio Frequency Identification (RFID), short-range wireless

communication, and WSN are used to realize the vision of IoT. With IoT, the physical objects or

physical world can be made available to (or accessed by) any computational system. Thus, we

could Google an object (key or book) which is enabled with RFID tag and locate the same inside

our home [1].


Why now

The reasons why IoT is gaining a lot of traction are due to advancement, standardization, or

adaptation in the following fields.

Development in embedded systems and sensors

Cloud Computing

Standardization of IPv6

Network capacity

Big Data Analytics

According to Gartner, Inc., there will be nearly 26 billion IoT-enabled devices by 2020 [5].

Gartner’s 2014 hype cycle reports IoT tops the hype cycle of emerging technologies.

Figure 1: Gartner Hype Cycle

http://en.wikipedia.org/wiki/Gartner


IoT Elements

Following are the basic elements that form an IoT ecosystem.

Nodes or Thing

A node or a thing is a required element of an IoT system. A thing or device is just a plain

hardware device or physical object. To make it part of the IoT ecosystem, things must have:

Sensing

Ability to sense the environment and obtain contextual data

Computing

Ability to receive a command from a centralized server or issue commands to the

actuators

Communication

The communication stack connects to other nodes or base stations. While the

communication could happen over wired or wireless medium, wireless is the

predominantly used medium in IoT ecosystem.

1. Bluetooth a. It is a low power consumption and used to communicate with other

devices in short distances

2. WiFi a. middle range – several hundred meters

3. WiMax / LTE / 3G / 4G a. a home gateway to the Internet

Gateway / Base Stations

Not all the nodes in IoT need to communicate to the internet. A few nodes could act as a base

station or a gateway node could be installed which will communicate back to a back-end

service. The base station or gateway node will be much bigger and have better processing

units.

Backend service

A backend server collects information from the thing and stores them in cloud-based storage.

Business value can be inferred by running various analytics or algorithms on the data.


Source: http://wiki.knoesis.org/index.php/Architecture_for_Open_IoT_Services

IoT Lifecycle

The lifecycle of a thing in an IoT ecosystem will have following phases [2].

Bootstrapping

Operational

Maintenance or re-bootstrapping

Decommission

Bootstrapping

Bootstrapping covers manufacturing, installation, and booting of a thing in the IoT ecosystem.

The lifecycle of a thing or device generally starts from its manufacturing phase. The device is

manufactured for a very particular purpose, e.g. to control room temperature.

http://wiki.knoesis.org/index.php/Architecture_for_Open_IoT_Services


Once manufactured the next step is to install it and bringing it up and running. This is called

commissioning the device. Here we install the device and configure it with required parameters..

Configuring could include the device identity and secret keys.

Certain security aspects/considerations are done during this phase. For example, will the device

have a hard-coded secret key? If so, can it be updated later? How about the algorithm to be

used? Does the device have the capability to be updated remotely or be replaced entirely?

These questions should be asked during this phase of the lifecycle.

Operational

In this phase, the things in IoT would be ready to communicate and would do what it is

programmed for. That is, it would observe the environment details and send it to the base

station or gateway device which would then communicate it back to the cloud server for storage.

Not all the things necessarily need to communicate to the backend sever. A few things could

work together to share the data about its state with the master node and this master node could

then send the data “collectively” to the back-end service.

Maintenance & Re-bootstrapping

The maintenance phase is tricky. In this phase we replace either the node itself (upgrading the

hardware) or upgrade just a few configurations (software upgrade). The IoT device generally will

last longer than the typical lifetime of an encryption/hash algorithm used. For example, the

lifetime of a smart meter might span over 50 years but that is not the same with cryptographic

algorithms. The best algorithm that’s available today might not be the same after 20 years.

Hence, we need to either update or replace the device. The maintenance aspect has to be

considered when details/configuration are put into the thing.

However, newly installed or reinstalled devices have to be bootstrapped again.

Decommission

This is the phase in which the device will be removed when it reaches EOL. A proper

decommission procedure has to be in place and followed to avoid leaking any data that is stored

in the decommissioned device.


Section 2: Technology Stack

Protocol Stack

Thus far, we have discussed the basic of IoT, its components, and lifecycle. In this section we

discuss the protocol stack that is developed to make the thing communicate with the Internet.

Protocols that were created to accommodate or enable the “thing” into the internet ecosystem

include:

6LoWPAN

IPv4 and IPv6 are for Internet-based protocols and IEEE 802.15.4 is for low power devices to

communicate with each other. 6LoWPAN (IPv6 over Low power wireless personal area

network) is a network layer protocol which acts as an adaption layer for these IPv4/IPv6 and

IEEE 802.15.4 networks.

The low power devices (sensors) in the WSN are designed to communicate using a proprietary

protocol. 6LoWPAN was defined to enable those devices to communicate over IP stack.

6LoWPAN defines the encapsulation and a header compression mechanism that allows the

IPv6 packets to be sent and received over IEEE 802.15.4-based networks.

IPv6

The main characteristics of IoT are the ability to address a thing in an IoT ecosystem. This is

possible with the adaptability of IPv6. With IPv6 the number of devices or objects or things that

can be addressable is 7.9×1028 X 4.3 billion[3]. With each device or object being identifiable they

can connect to the Internet seamlessly. However, not every device needs to be connected to

the Internet. The typical deployment scenario would be to have a gateway which will

communicate to the outside world via the Internet and other devices (home appliances) could

communicate to this gateway regarding their status. Also, in actual use, IPv6 addresses are

structured for routing and other purposes and as a result the number of addresses available is

effectively less, but still extremely large


CoAP

Constrained Application Protocol (CoAP) is a web transfer protocol from Internet Engineering

Task Force (IETF) that is intended for use in resource-constrained Internet devices, such as

WSN nodes. It is a specialized web transfer protocol based on UDP that provides a subset of

functionalities provided by HTTP. It is designed for small low power sensors, switches, valves,

and similar components that need to be controlled or supervised remotely, through standard

Internet networks.

CoAP provides a request/response interaction model between application endpoints, supports

built-in discovery of services and resources, and includes key concepts of the Web such as

URLs and Internet media types. CoAP is designed to easily interface with HTTP for integration

with the Web while meeting specialized requirements such as multicast support, very low

overhead, and simplicity for constrained environments.

CoAP supports the REST model and the actions it supports (GET, PUT, POST, and DELETE)

are similar to HTTP Verbs.

There is an open source implementation for CoAP protocol. To know more please, check out

https://www.eclipse.org/californium/.

Source: http://wiki.knoesis.org/index.php/Architecture_for_Open_IoT_Services

https://www.eclipse.org/californium/

http://wiki.knoesis.org/index.php/Architecture_for_Open_IoT_Services


RPL

Once we have the data that needs to be shared, it needs to be routed to the destination (via

Gateway). In traditional Internet, the routing is done based on the routing table. However, the

same cannot be followed for the Low Power & Lossy network (LLN). Hence, IETF formed a new

working group (ROLL) and a new specification RPL (pronounced “ripple”) was created to

address the routing needs for LLN environments[4]. RPL plays a crucial role in delivering

packets or data in IoT environments.

MQTT

MQ Telemetry Transport (MQTT) is a M2M/"Internet of Things" connectivity protocol. It is a

publish/subscribe, extremely simpl,e and lightweight messaging protocol, designed for

constrained devices and low-bandwidth, high-latency or unreliable networks. The design

principles are to minimize network bandwidth and device resource requirements whilst also

attempting to ensure reliability and some degree of delivery assurance.

Though invented in 1999, it is in the process of standardization by OASIS as of March 2013[6].

Section 3: Security Aspects

The term security refers a wide range of concepts. At minimum, it refers to confidentiality,

integrity, and availability aspects of a given entity or object. Apart from these, a few more

aspects to consider are authentication, authorization, and non-repudiation. These security

services can be implemented by means of different cryptographic mechanisms, such as block

ciphers, hash functions, or signature algorithms. For each of these mechanisms, a solid key

management infrastructure is fundamental to handling the required cryptographic keys.

Challenges

The miniature size or limited capability with the CPU and memory restricts using security

solutions directly from current IT systems. Following are some of the unique challenges /

concerns applicable to IoT from its lifecycle perspective.

Bootstrapping

Device cloning

When a device is manufactured and shipped to the user for installation, how can we be sure or

trust the device is indeed from the trusted manufacturer. What if the device is cloned and

shipped or sold in the market under the same name? A proper mechanism has to be in place to

tackle this issue. Code Signing could generally be used here to mitigate this threat.


Forming Trust Domain

This is the first step in establishing the network/ecosystem of IoT to be communicated in a

trusted manner. Once the device is installed and switched on, a secure domain will be formed to

which all the related IoT devices will join securely. The two approaches to achieve this are:

Centralized

The most common approach is to have centralized architecture where there will be a center

party within a security domain who will perform all security related management operations. This

has a few pros and cons as well.

Pros

Centralized management of devices

Centralized management of cryptographic keys or other security related parameters / configuration

Cons

Single point of failure

Online connectivity required by other nodes to form a domain

No way to form an ad hoc domain without a security infrastructure

In a centralized architecture, preconfigured keys or certificates held by a thing can be used for

distribution of operational keys in a given security domain.

Distributed

In distributed mode, two nodes might form an ad hoc secure domain and communicate with

each other to accomplish tasks. The ad hoc domain can later be added to the centralized node

for further management. In a distributed approach, a Diffie-Hellman type of handshake can

allow two peers to agree on a common secret. In general, IKEv2, HIP, TLS, and DTLS, can

perform key exchanges and the setup of security associations without online connections to a

trust center. However, the resource constraint (size of the device and available CPU) might

place restrictions on this approach.


Operational

Possible threats that need to be considered when an IoT device is operational or ready to serve.

Authentication

Proper Authentication & Authorization has to be in place for a thing that accepts commands

from a remote device. Serving an unauthenticated request might lead to information leak and

risk the overall security and privacy of the IoT ecosystem. Also, sharing data with an unknown

or untrusted entity or node can compromise data privacy.

Denial of Service

The miniature size of IoT and the constraint imposed by the IoT with respect to computation

power, low bandwidth communication channels, CPU, memory, and energy restricts usage of

current IP-based protocols.

For example, IEEE 802.15.4 supports 127-byte sized packets at the physical layer which may

result in fragmentation of larger packets of security protocols. This may open up new attack

vectors of denial of service (DoS). The packet fragmentation will result in performance

degradation as well. Hence, the size and number of messages (or packets) has to be minimized

to reduce the memory requirement and optimize the bandwidth usage available in the “thing”.

Security protocols in general have to reduce the cryptographic cost of required public key-based

key exchanges. If the cryptographic cost is high in terms of computational power, restricted

device DoS is very possible for devices with low CPU or memory.

Malware

Many point-of-sale (POS) systems are impacted due to malware. Malware are designed to work

in a specific way to attack a specific device. What mechanisms are in place to protect against

these type of attacks? Having anti-virus software could be an issue with very small devices with

very little CPU power. Consequently, the ability to detect the malware has to be built in to the

device hardware itself.



A thing that is part of IoT needs to have a mechanism to handle or recover from single point of

failure. This could be caused by a remote attack (e.g. flood the device with multiple requests so

that it will crash) or a physical attack. Such a mechanism will ensure the thing will be available

all the time.

Botnet

A compromised IoT can be act like a botnet which can then launch an attack. With a proper IT

policy is in place (e.g. firewall rules), this situation could to be handled.

Key Management

During the operational phase, the IoT devices will form a trusted circle or secure domain to

enable all IoT devices in the trusted circle to communicate with each other in a secured manner.

Keys that are stored in memory has to be secured since a compromise in the secret keys would

result in a typical man in the middle or eavesdropping attack.

Protocol translation

IoT talks in different protocols than the Internet protocol. 6LoWPAN and CoAP reduce the gap

between IP and IoT protocol by providing a protocol translator at the gateway to handle this

scenario. However, they introduce a major hurdle in end-to-end security measures between IoT

devices and the Internet host. IKEv2 and HIP, TLS, and DTLS provide end-to-end security

services including peer entity authentication, end-to-end encryption, and integrity protection

above the network layer and the transport layer, respectively.

Mobility Support

It is expected that many things (e.g. wearable sensors and user devices) will be mobile in the

sense that they are attached to different networks during the lifetime of a security association.

Built-in mobility signaling can greatly reduce the overhead of the cryptographic protocols

because unnecessary and costly re-establishments of the session (possibly including

handshake and key agreement) can be avoided.

Backdoor / Monitor Interface

Vendors put a backdoor into the device to maintain it/monitor the same. The issue comes when

this is not disclosed or tested for security vulnerability. For example, while a vendor could put a

backdoor which is used to upgrade the software that is running inside the device, have general

security practices been followed? Is authentication/authorization in place? How is the credential


stored in the device? Is the password/credential sufficiently complex so that it cannot be

guessed?

Maintenance & Re-bootstrapping

Patch management

What has been the mechanism/practices for applying patches? Typical enterprise networks

have an IT admin who monitors each software version and applies the appropriate security

patches. However, when it comes to home appliances of IoT which end users are using,

monitoring and applying patches to each of the things is tedious work. Also, the onus to apply

the patches has to be identified.

Firmware replacement

Hardware exploitation can occur when a legitimate device replaced with a bogus one.

Decommission

A decommissioned device retaining residual data could lead to an information leak. Proper

measures or procedures have to be in place for decommissioning a device or a thing.

Mitigations

The following are a few best practices / design / security controls that need to be considered to

make the IoT safer and more trustworthy.

Manufacture

Security has to be in place right when the device is manufactured. There should be mechanisms

to verify the IoT-enabled device has been manufactured by the trusted manufacturer.

Authentication of a “thing” has to be done before it joins or communicates with the other trusted

“thing” (or joining an IoT trust circle). Code signing and code obfuscation are some steps which

manufacture can follow to ensure their device isn’t hacked or unwanted code is inserted by a

malicious user. PKI can be enabled to ensure device authenticity.

Also, the manufacturer has to determine how the IoT will be managed.

Patch the embedded systems (or)

Have an end of life date for these devices, after which it will be replaced entirely.

Both approaches above have their own challenges. The first approach — patching — needs a

robust and trusted environment to apply the patch automatically and centrally. Otherwise, it runs

the risk of compromising the single central system which, in turn, may compromise the IoT. The

http://tools.ietf.org/html/rfc3748














second approach — having an end of life for the IoT — is good but the device has to be

inexpensive enough for one to replace it physically rather than patching it.

Device manufacturers should work closely with security researchers to validate the device.

Perhaps there should be a consortium or team who approves the device before it is shipped as

IoT. Security has to be part of the product, rather than installing a separate product along with

IoT that secures it.

Also, a process has to be in place for security researchers to report the vulnerability directly to

the vendor. For example, a security researcher has to disclose the vulnerability to a vendor via

Twitter since there wasn’t a best process in place for a white hat researcher to report the

vulnerability [7].

Resilience to common attacks

The component that is part of IoT has to be able to withstand various attacks. For example, the

communication medium should have measures in place to respond to eavesdropping or

physical jamming attacks or other common wireless- related attacks.


A thing that is part of IoT needs to have a mechanism to handle or recover from single point of

failure. This could be caused by a remote attack (e.g. flood the device with requests so that it

will crash) or physical attack. Such a mechanism will ensure the thing will be available all the

time.

To handle malware- related attacks the IoT should be designed to detect the anomaly and

isolate itself from the network or not to issue the command/take an appropriate course of action.

Default Configuration

IoT shouldn’t be operated with default password. During the bootstrapping phase, force the user

to change the default password with a complex one.

Security Standards

The security Industry needs new technologies to secure IoT. New standards /compliance has to

be created to which the manufacture must comply. Unless businesses enforce security,

manufacturers of IoT won’t consider security as part of developing their IoT product since they

have no real incentive to do so. The consumer won’t be concerned about security until serious







http://en.wikipedia.org/wiki/Internet_Key_Exchange#cite_note-rfc4322p5-3












damage is done and it makes the headlines. A standard should be put in place to ensure the

products developed are certified and are easy for the consumer to identify before using.

Complexity of the system

IoT should be designed with simplicity in mind. IoT device should be built only with specific

duties and not be overloaded. For example, don’t connect to the Internet if that feature isn’t

needed.

Also, break down IoT networks into different segments or zones. Having different zones would

enable categorizing that a certain zone can communicate to the Internet via a specific DMZ.

Different policies could be based on different zones as well.

System Monitoring

Monitoring is the best way to detect anomalies. An intelligent decision can only be made based

on the available data. Thus, an IoT device should be capable of reporting its status and

operation to a centralized system which can be used later to detect the anomaly. Generally,

SIEM products will be used to monitor the log events. However, SIEM products typically rely

either on syslog reporting capabilities or cooperative host-based agents on endpoints to collect

information.

Privacy Enhancing Technologies

The communication channel should never be on a plain text. With IoT, it’s hard to categorize the

data as sensitive or non-sensitive. Since the data is about the user (either their usage or about

their environment) all the data must be considered sensitive. For example, if a smart meter is

below its usual load, an attacker could infer no one is home. This is sensitive data from the user

perspective. Encryption of the data has to be part of the protocol stack which secures the data

during the data transit.



Section 4: Adoption of IoT

Gartner estimates there will be a 26 billion devices connected in the IoT space. Meanwhile,

Cisco estimates the business opportunity to be around $19 trillion. Though these are estimates,

actual adoption will rely on:

Open Standards – There needs to be open standards in terms of IoT architecture,

protocols, and implementation. We have seen the impact of open source/standards in

the web development (Web 2.0). Similar impact should happen in the IoT space as well

to see adoption of IoT in the market.

Affordability – Cost will be a huge factor in driving IoT adoption, especially in

developing countries. A great example would be a mobile (or smart phone) in India. The

availability of inexpensive smart phones has resulted in mobile phones to reaching

billions of people in India.

Ease of Use – The IoT ecosystem should make use of current devices for a gateway

rather than coming up with new ones. For example, a smart phone could be used as a

gateway or remote controller for IoT ecosystem for a consumer. Also, the aesthetic

aspect of the IoT device (wearable) has to be considered.

Security – Security and privacy are key in building investor confidence and consumers

to adoption of IoT-based products.

Adaption in India

Below are a few initiatives or examples around IoT applications in progress in India.

NanoGanesh has come with a various products that help in irrigation space [9].

Smart city is being implemented in “Electronic City, Bangalore” for smart parking, smart CCTV

surveillance, smart street lighting, smart water management, and community messaging. This

pilot project is being developed in partnership by Cisco and the Electronics City Industries

Association (ELCIA). This project is expected to go live by 2015 [10].

A healthcare-related project, CypHys+[8], is being developed by IISC (Indian Institute of Science)

and funded by DeitY (Department of Information Technology) based on IoT technologies. The

idea is to share medical data about the patient for preliminary analysis by the doctor. Data

collected include blood pressure (BP) and electrocardiogram (ECG). Work is also being done on

“Fall Detection” so patients will get immediate help when unexpected fall incidents occur.


Conclusion

IoT is a disruptive technology that touches many product areas. IoT ecosystem will give more

data or context about each device, which brings a huge amount of data for its own analysis and

infer new business opportunities. However, one has to weigh the benefit-risk ratio before

connecting a “thing” to the Internet.

There is still more research to be done and challenges need to be addressed before we see

wide-spread adoption of IoT. Focus areas include standardization, bandwidth

availability/manageability, and other security challenges. Initially, there will be a very

conservative approach to IoT adoption (very similar to Internet). However, stable IoT

deployment along with proven security and privacy control measures, could accelerate IoT

adoption by consumers. Gaining users’ trust with the IoT ecosystem will be huge challenge.

The current model, infrastructure, and standards of IT won’t satisfy IoT needs. We need to

rethink our existing model, infrastructure, policy, and standards from bottom-up with IoT needs.



References

https://www.dei.unipd.it/node/23331

https://tools.ietf.org/html/draft-garcia-core-security-06

http://en.wikipedia.org/wiki/IPv6

https://tools.ietf.org/html/rfc6550

http://www.gartner.com/newsroom/id/2636073

http://en.wikipedia.org/wiki/MQTT

http://arstechnica.com/security/2013/08/philips-hue-lights-malware-hack/

http://www.ece.iisc.ernet.in/cyphys/

http://www.nanoganesh.com/

http://newsroom.cisco.com/release/1450506

EMC believes the information in this publication is accurate as of its publication date. The

information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION

MAKES NO RESPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO

THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an

applicable software license.

https://www.dei.unipd.it/node/23331

https://tools.ietf.org/html/draft-garcia-core-security-06

http://en.wikipedia.org/wiki/IPv6

https://tools.ietf.org/html/rfc6550

http://www.gartner.com/newsroom/id/2636073

http://en.wikipedia.org/wiki/MQTT

http://arstechnica.com/security/2013/08/philips-hue-lights-malware-hack/

http://www.ece.iisc.ernet.in/cyphys/

http://www.nanoganesh.com/

http://newsroom.cisco.com/release/1450506

Documents

IOTECURITY & PRIVACY PERSPECTIVE —S