Re: [m2m-iwg] Chair position at M2M IWG

[UOMo <uomo@xxxxxxxxxxx>]

No "White Smoke" on that yet?

Sorry to see you leave, Scott. Best of luck with your new role.

Werner

On Wed, Mar 13, 2013 at 10:28 PM, <m2m-iwg-request@xxxxxxxxxxx> wrote:

Send m2m-iwg mailing list submissions to
        m2m-iwg@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        http://dev.eclipse.org/mailman/listinfo/m2m-iwg
or, via email, send a message with subject or body 'help' to
        m2m-iwg-request@xxxxxxxxxxx

You can reach the person managing the list at
        m2m-iwg-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of m2m-iwg digest..."


Today's Topics:

   1. Re: Consumer device security (was: M3DA presentation)
      (Rick Bullotta)
   2. Re: Chair position at M2M IWG (Scott de Deugd)


----------------------------------------------------------------------

Message: 1
Date: Wed, 13 Mar 2013 19:06:57 +0000
From: Rick Bullotta <rick.bullotta@xxxxxxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] Consumer device security (was: M3DA
        presentation)
Message-ID:
        <C7D31C647F791B439B6E65E10053D5370D98B778@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Content-Type: text/plain; charset="us-ascii"

Pretty much my exact perspective as well.

Though I don't think the industry/consumer boundary is necessarily the delimiter, more like "intranets of things" vs the "internet of things".  For many of the reasons you outline, many of the IoT/M2M scenarios that the general population hear about (Smart Grid, Smart Whatever) will not necessarily use the general Internet, at least not for a long time.  But that doesn't necessarily change the security requirements for authentication, identification, verification, authorization and encryption.

Another (oversimplified) delineation point is read vs write.  Reading your dog's current location or the energy usage in your house is one thing, but turning appliances on and off and updating the software on your car's antilock brakes is a whole different world.  Even in the "read" scenario, data that is used in business logic that ultimately results in actuation or action needs to be verified and validated.  And of course, sensitive data, such as healthcare, brings yet another host of concerns.

Short answer is that there neither a single set of requirements nor a single solution.  But there are gaps that need to be addressed, and the more standardized these could be, or the more they can be accomplished at the lowest layers of the stack, the better...

Cheers,

Rick

From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On Behalf Of T-Rob
Sent: Wednesday, March 13, 2013 2:17 PM
To: m2m Industry Working Group
Subject: [m2m-iwg] Consumer device security (was: M3DA presentation)

The interesting aspect of the discussions of late, at least to me, are that they are entirely focused on connection security.  In the industrial M2M space, there was a heavy reliance on physical controls and little or no security in the operations side of the network.  Eventually the Ops network was upgraded to include connection security but the messages showing up over those secure connections are usually assumed to be intact and authentic.  This new security architecture (arguably) works because of a closed network with TLS guarding the perimeter.  The devices are trusted and inside a perimeter which is itself also trusted, so the messages are trusted.

But the physical and perimeter controls present in industry won't be there in the consumer space where it's necessary to assume that the devices themselves are hostile and the perimeter is porous.

Industry has also traditionally had one owner for all the data.  It is collected, correlated, analyzed and acted on by a single entity.  If not a single legal entity, then a single entity from a trust perspective.  It goes from the plant to the control room to the Enterprise.  Possibly it goes to 3rd parties but there is an inherent trust that the data is assumed to be intact and authentic because it arrives over an authenticated connection from a trusted source.

This will also not be true in the consumer space where data will be used by multiple parties, where the first owner is not the only one who requires integrity and authenticity, and where the first owner must be assumed to be untrustworthy by second-tier users of the device data.  (Not necessarily by untrustworthy character so much as by virtue of the porous network and lack of physical controls.)  People will want to be first owners of their data and vendors transacting business based on device data need to know it is authentic and intact.

Based on these observations, it seems to me that securing the data is a hard prerequisite to IoT in the consumer space - homes, autos, many offices.  Connection security remains integral, especially for administrative connections, but I don't see it as the foundation of trust for device data in the consumer space.

Has anyone else arrived at that conclusion?  If I'm wrong, where am I wrong?  The assumptions about how consumer space differs from industry?  The unwillingness of consumers to use "smart" devices where they are not the first owner of the data?  The assumption that device data will drive multi-party financial transactions?  The assumption that the consumer network is inherently porous and that legitimately provisioned devices must be assumed hostile?

On the other hand if I'm correct or even close on the assumptions and conclusion then is there any work being done on signed data in this group?  I'd like to participate and I'm keen to get industry participants hooked up with people in the VRM and pClouds groups who also see this as a requirement and are looking to make progress on it.  Or does this group see that as the developer's responsibility?  Because solving this problem in the application creates walled gardens but solving it in the transport creates an ecosystem.

Cheers -- T.Rob


m2m-iwg-bounces@xxxxxxxxxxx<mailto:m2m-iwg-bounces@xxxxxxxxxxx> wrote on 03/13/2013 07:25:47 AM:

> From: Fabien Fleutot <fleutot@xxxxxxxxx<mailto:fleutot@xxxxxxxxx>>
> To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx<mailto:m2m-iwg@xxxxxxxxxxx>>,
> Date: 03/13/2013 07:26 AM
> Subject: Re: [m2m-iwg] M3DA presentation - Security
> Sent by: m2m-iwg-bounces@xxxxxxxxxxx<mailto:m2m-iwg-bounces@xxxxxxxxxxx>
>
> M3DA security addresses another M2M issue: key provisioning. In
> practice, it's often hard to mass-manufacture devices with
> individual keys in their firmware. What we see is that more often
> than not, a whole fleet of devices end up sharing the same
> authentication key, with the results you can imagine if that key is
> compromised.
>
> M3DA mitigates that risk with two levels of keys: there's a
> provisioning key, which is shared by several devices, but is only
> used to exchange the actual, unique-per-device authentication key
> (we call them "registration password" and "passsword" respectively).
> The password provisioning is performed the first time the device
> connects to the network, possibly in factory during tests; by
> default, the server will refuse to re-provision a password which has
> already been provisioned, thus thwarting identity theft attempts.
>
> A full TLS or SSH tunneling solution, with unique keys provisioned
> during manufacturing, a full PKI to back it, and an effective
> revocation system, is preferable to M3DA in some cases; but it's
> hard enough to deploy that in practice, many people simply roll out
> a lousy shared password scheme, optionally with an illusion of
> security brought by the (mis)use of a TLS stack. M3DA is much better
> than the naive solution, without being harder to deploy.
> _______________________________________________
> m2m-iwg mailing list
> m2m-iwg@xxxxxxxxxxx<mailto:m2m-iwg@xxxxxxxxxxx>
> http://dev.eclipse.org/mailman/listinfo/m2m-iwg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130313/da82fc13/attachment.html>

------------------------------

Message: 2
Date: Wed, 13 Mar 2013 17:28:11 -0400
From: Scott de Deugd <dedeugd@xxxxxxxxxx>
To: mike.milinkovich@xxxxxxxxxxx,       m2m Industry Working Group
        <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] Chair position at M2M IWG
Message-ID:
        <OF0469015C.D970A1C2-ON87257B2D.0075D9C3-85257B2D.0075F1E1@xxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Mike, I've  no name yet but should very soon.

........................Scott



From:   "Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx>
To:     "'m2m Industry Working Group'" <m2m-iwg@xxxxxxxxxxx>
Date:   03/13/2013 02:15 PM
Subject:        Re: [m2m-iwg] Chair position at M2M IWG
Sent by:        m2m-iwg-bounces@xxxxxxxxxxx



Scott,

To echo Ian?s comments, thank you very much for all of your hard work in
getting the M2M IWG off to a great start. Best of luck with your new role
at IBM.

I note that you are also IBM?s representative on the steering committee.
Has IBM named a successor to you for that role?

Mike Milinkovich
mike.milinkovich@xxxxxxxxxxx
+1.613.220.3223

From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On
Behalf Of Scott de Deugd
Sent: March-13-13 1:06 PM
To: m2m Industry Working Group
Subject: [m2m-iwg] Chair position at M2M IWG

In advance of our F2F meeting at EclipseCon, I would like to announce the
availability of the position of Chair for the M2M IWG.

I have a new assignment beginning soon at IBM, and will no longer be able
to maintain this role for the IWG,  With the upcoming F2F meeting, it
seemed like an excellent time to start the process of finding a new Chair.
 Ian will advise us further on the process steps.

I have truly appreciated the opportunity offered me to contribute to
getting the M2M IWG off the ground.   IBM remains committed to the M2M IWG
and related  Eclipse open source projects.  I personally will work to
ensure the transition goes smoothly.

There are very strong teams at Eclipse, on the IWG and the projects.  I
encourage everyone to consider this role.

best regards.................Scott

 _______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130313/0e885c53/attachment.html>

------------------------------

_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg


End of m2m-iwg Digest, Vol 17, Issue 17
***************************************