

IoT Anxieties in McKinsey-GSA Study - mtuncer
http://www.eetimes.com/author.asp?section_id=36&doc_id=1326597

======
MichaelCrawford
I don't want my Things to be on the Internet. I am so adamant about that that
I won't even apply to IoT jobs.

While the common concern is that they have poor security, that's not my
concern. What I don't want is for my refrigerator to let my grocery store know
that I'm out of milk.

When I'm out of milk, I'll go to the grocery store to pick some up myself -
then pay cash.

~~~
watty
Then don't by a "smart refrigerator" or connect your refrigerator to the
internet. IoT isn't being forced on people, people are embracing IoT.

~~~
alkonaut
You basically can't buy a TV these days and NOT connect it to the Internet, as
the buggy firmware isn't fixed until long after is sold. Granted, you can use
a usb stick and patch it yourself every now and then, much like your car is
updated at service (but how long until cars are updated, and hacked,
remotely?)

~~~
neonfreon
Easy solution: don't configure wifi on the TV.

~~~
pdkl95
That is harder that it sounds in many places, because you don't get to
(easily) control the radio signals that cross your house. Windows set a (very
bad) precedent a long time ago that devices auto-connect to new networks, so
your TV could be using your neighbor's wifi automatically.

That's just the short term problem while 802.11 chips are the cheap device
preferred by hardware manufacturers. This will get a _lot_ harder to block
when the LTE/WiMAX/HSPA/etc chips become cheaper and the device manufacturers
start negotiating deals with the network owners for cheap low-priority batch-
job rates. Your TV can store what you've been watching as long as necessary,
and upload whenever the cellular network is quiet. Precedent for embedding a
cellular radio already exists with "onstar".

I seriously doubt anybody checks that their electronic devices aren't
uploading personal data at 3:27AM once or twice a week.

------
joezydeco
Annnnd here we go into the Trough of Disillusionment:

[http://en.wikipedia.org/wiki/Hype_cycle](http://en.wikipedia.org/wiki/Hype_cycle)

I'm doing a lot of IoT work in the B2B area, where I think these things are
going to pick up a lot of traction before the consumer stuff really takes off.

Part of the problem I see is that the chipmakers, at least the ones still
standing after Apple and Samsung took the application processor market away
from them, are trying to reassure their investors that IoT is a the new
revenue stream they all need to look forward to. Looks like they're finally
getting that reality check they needed.

The problem is that IoT isn't just a part in a BOM. It's an entire
infrastructure that needs to be in place to support it. Even on the B2B side,
I can put a wifi chip into a backend technology demonstration and convince the
customer they need it...until I ask them what their plans are to host the data
and develop the front-ends. Complete blank stares. There are too many parties
involved to design this stuff front to back. Perhaps the first company to sell
the chip AND the hosting service as one unified package will make headway
here.

This still will mature and prosper...in time. Just not yet.

~~~
HeyLaughingBoy
That's actually been happening for a while. Not at the chip level, but
businesses providing hosting, analytics services and hardware modules (i.e., a
"box" with some I/O and WiFi) as a one-stop shop. Besides Bosch (who entered
the business by an acquisition), I can't think of names off the top of my
head, but they are out there. Axeda was a big player in the hosting for remote
monitoring arena about 10 years ago, but I don't think they ever sold
hardware.

More interesting is that I'm already hearing about the companies that are
dropping offerings: no longer selling hardware, but just doing hosting and
analytics. I don't know if this is due to the hype dying off (doubt it) or
just discovering it's more profitable to not have to inventory & support
hardware.

And I am also seriously considering exactly this. Have the experience, have
(most of) the skillset. Just need to figure out who the customers will be.

------
Tehnix
I haven't read the article, since the page fails for some reason (getting a
contact support message).

Despite that, I'm personally quite excited about IoT. It doesn't just have
huge potential in bigger manufactoring processes and places where monitoring
and decision making can be automated to a large degree, but also personal
value in home automation.

I'm currently writing my thesis which focuses on reactive events, in the sense
that devices can subscribe to specific events and they also post their own.

For example: the light in the entrance of your house is connected and will
transmit the event,

    
    
        {device: 'Light', location: 'Entrance', value: 'On'}
    

which your thermostat in your living room has subscribed to. It will then
receive this event and based on the value, in this instance 'On', change the
room temperature by either raising or decreasing it.

I'm very fond of automating things on my computer, so bringing stuff like this
into the real world, in an easy way is one of the goals. After my thesis is
done I will open-source it, and it'll hopefully be something that people can
actually use.

------
hacknat
It's funny to me when people try to predict where either the success or
failure of a whole concept will come from and when it is supposed to happen.
Nobody really knows what IoT is yet.

The exact same thing happened in the early days of the web. People thought
search wasn't a big deal; they thought people would buy ice online; they
thought that the web should be completely overhauled and replaced with binary
executables that we could all browse. When it all collapsed the first time, a
lot of people thought that the promise of the web was over.

IoT is in roughly the same place that the web was in the early 90s. I'm
hesitant to say this is a trough of disappointment, because I don't think that
enough of the key technologies have emerged yet that are going to make
connected things an actual convenience to people.

I think the problems that skeptics see actually could be problems, but it
really is to early too tell. The problems they see could be problems or they
could simply be gaps that haven't been filled yet.

------
mark_l_watson
""As the McKinsey-GSA report points out, a major challenge is the security and
privacy of user data.""

That, I think, is the heart of the issue. I am working on a new book ("Power
Java", with a similar version "Power Clojure") that has a section on IoT. I
mention security as a problem, but don't much address the security issues.

The problem is that the model for IoT is discovery of nearby services. If a
user has to stop and manually authenticate, it spoils things. Perhaps devices
could have unique security tokens and you could verify other devices once.

------
DyslexicAtheist
funny when people with clearly no idea about standardization reurgitate some
points from a high-level business consultancy who has also no idea about
technology standardizations. In all my years sitting in WG's at ETSI and ITU-T
I have not once met a delegate from McKinsey so how do people find them a
credible source of info and authority to speak on the subject?

For a start ETSI deleivered a pretty complete standard on M2M:
[http://www.etsi.org/deliver/etsi_ts/102600_102699/102690/02....](http://www.etsi.org/deliver/etsi_ts/102600_102699/102690/02.01.01_60/ts_102690v020101p.pdf)

yes this is work in progress but so is anything the W3C does.

If that is not enough then below some further reading if you think
standardization is still incomplete. IMO this article along with the original
report is utter bullcrap because it confuses lack of standards with
"unwillingness to play by these standards" (mostly zigbee):

[1] ETSI TS 102 921: "Machine-to-Machine communications (M2M); mIa, dIa and
mId interfaces".

[2] IETF RFC 6267: "MIKEY-IBAKE: Identity-Based Authenticated Key Exchange
(IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)".

[3] IETF RFC Draft: "An EAP Authentication Method Based on Identity-Based
Authenticated Key Exchange". [4] IETF RFC Draft: "IBAKE: Identity-Based
Authenticated Key Exchange".

[5] ETSI TS 124 109: "Universal Mobile Telecommunications System (UMTS); LTE;
Bootstrapping interface (Ub) and network application function interface (Ua);
Protocol details (3GPP TS 24.109)".

[6] OMA-AD-DM-V1-3: "Device Management Architecture", Version 1.3.

[7] OMA-TS-DM-Notification-V1-3: "OMA Device Management Notification Initiated
Session", Version 1.3.

[8] OMA-TS-DM-Protocol-V1-3: "OMA Device Management Protocol", Version 1.3.

[9] OMA-TS-DM-Sessionless-V1-3: "OMA Device Management Sessionless Message",
Version 1.3.

[10] Broadband Forum TR-069: "CPE WAN Management Protocol" Version 1.3, Issue:
1 Amendment 4. Issue Date: July 2011. NOTE: Available at
[http://www.broadband-
forum.org/technical/download/TR-069_Ame...](http://www.broadband-
forum.org/technical/download/TR-069_Amendment-4.pdf)

[11] OMA-TS-MLP-V3-3-20110719-A: "Mobile Location Protocol", Version 3.3.

[12] ETSI TS 123 271: "Digital cellular telecommunications system (Phase 2+);
Universal Mobile Telecommunications System (UMTS); LTE; Functional stage 2
description of Location Services (LCS) (3GPP TS 23.271)".

[13] OMA-TS-DM-StdObj-V1-3-20101207-C: "OMA Device Management Standardized
Objects", Draft Version 1.3.

[14] Broadband Forum TR-106: "Data Model Template for TR-069-Enabled Devices",
Issue: 1 Amendment 6".

[15] OMA-TS-DM-TND-V1-3: "OMA Device Management Tree and Description", Version
1.3.

[16] OMA-TS-DCMO-V1-0: "Device Capability Management Object", Version 1.0.

[17] Broadband Forum TR-157: "Component Objects for CWMP, Issue: 1 Amendment
6".

[18] OMA-TS-DiagMonFunctions-1-0: "DiagMon Functions Supplemental
Specification", Version 1.0.

[19] Broadband Forum TR-181: "Device Data Model for TR-069", Issue 2 Amendment
4.

[20] OMA-TS-LAWMO-V1-0: "Lock and Wipe Management Object", Version 1.0.

[21] OMA-TS-DiagMonTrapMOFrame-V1-2: "Diagnostics and Monitoring Trap
Framework Management Object", Version 1.2.

[22] OMA-TS-DiagMonTrapEvents-V1-2: "Diagnostics and Monitoring Trap Events
Specifications", Version 1.2.

[23] OMA-TS-DiagMonMO-V1-0: "Diagnostics and Monitoring Management Object",
Version 1.0.

[24] OMA-TS-DM-FUMO-V1-0: "Firmware Update Management Object", Version 1.0.

[25] OMA-TS-DM-SCOMO-V1-0: "Software Component Management Object", Version
1.0.

[26] OMA-TS-GwMO-V1-0: "Gateway Management Object Technical Specification",
Version 1.0.

[27] ETSI TS 102 671 (V9.0.0): "Smart Cards; Machine to Machine UICC; Physical
and logical characteristics (Release 9)".

[28] ETSI TS 102 310 (V9.0.0): "Smart Cards; Extensible Authentication
Protocol support in the UICC (Release 8)".

[29] ETSI TS 133 220: "Digital cellular telecommunications system (Phase 2+);
Universal Mobile Telecommunications System (UMTS); LTE; Generic Authentication
Architecture (GAA); Generic Bootstrapping Architecture (GBA) (3GPP TS
33.220)".

[30] ETSI TS 187 003 (V2.3.2): "Telecommunications and Internet Converged
Services and Protocols for Advanced Networking (TISPAN); NGN Security;
Security Architecture".

[31] ETSI TS 102 484: "Smart Cards; Secure channel between a UICC and an end-
point terminal (Release 9)".

[32] IETF RFC 2046: "Multipurpose Internet Mail Extensions (MIME) Part Two:
Media Types".

[33] IETF RFC 2560: "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP".

[34] IETF RFC 2663: "IP Network Address Translator (NAT) Terminology and
Considerations".

[35] IETF RFC 2716: "PPP EAP TLS Authentication Protocol".

[36] IETF RFC 4366: "Transport Layer Security (TLS) Extensions".

[37] IETF RFC 3748: "Extensible Authentication Protocol (EAP)".

[38] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".

[39] IETF RFC 4186: "Extensible Authentication Protocol Method for Global
System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)".

[40] IETF RFC 4187: "Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA)".

[41] IETF RFC 4346: "The Transport Layer Security (TLS) Protocol Version 1.1".

[42] IETF RFC 5216: "The EAP-TLS Authentication Protocol".

[43] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".

[44] IETF RFC 6066: "Transport Layer Security (TLS) Extensions: Extension
Definitions".

