Re: [m2m-iwg] Consumer device security (was: M3DA presentation)

[T-Rob <t.rob.wyatt@xxxxxxxxxx>]

Hi Cuero,

I suppose that I'm making a fine distinction when I say "sign the data" 
between something that is a transport versus something that is useable 
outside the context of the transport.  The use case I'm looking for is 
that there may be multiple legitimate recipients of device data who 
require integrity and authenticity.  This may either be multiple 
subscribers adjacent to the device, or possibly recipients located one or 
more hops distant from the device.  If I understand the M3DA spec 
correctly, this use case isn't met.  This is why I asked whether anyone in 
this group was working on something that signed data.  In future, I'll try 
to express my requirement more clearly.  It isn't signed data I'm looking 
for so much as integrity, authenticity and possibly non-repudiation 
services bound to data rather than to connections. 

Although my example use case is multiple data recipients, the general use 
case is based on the value of networks as a function of connection 
density.  The value of 50 billion devices connected point-to-point may be 
great but the value of 50 billion devices capable of integrity, 
authenticity and non-repudiation over native pub/sub is infinitely 
greater. 

I realize that what I'm seeking requires certificates and PKI but 
unlocking the potential of multiple first recipients and greater 
connection density would seem to be well worth the trouble.  Fabien said 
PKI would be preferable to M3DA "in some cases" but I believe the actual 
ratio is the inverse.  Unless the objective is to prevent SkyNet from 
becoming self-aware, we'd need PKI in *most* cases.  We gain ease of 
provisioning device identity but in doing so we restrict the number of 
recipients capable of trusting that data from many down to exactly one.

In fact, if I understand the spec correctly, M3DA requires the device to 
be booted up and the device/server keys exchanged before leaving the 
factory, or else it needs to build a server-authenticated TLS connection 
before exchanging keys, so it isn't clear how much administrative overhead 
saved with M3DA vs. X.509.

This is not to disparage M3DA in general, I'm sure it is great for its 
intended use cases.  But I believe there's a singularity point beyond 
which the primary use cases will require binding security to the data 
instead of the connection so that we can achieve the connection density 
required to do useful things with 50 billion devices.  That point appears 
to be approaching quickly and already closer than we realize so I'm 
looking for ways to address it now and still hoping to find someone 
working on it, or to convince someone else that it's worth working on. 

Kind regards,
-- T.Rob





From:   Cuero Bugot <cbugot@xxxxxxxxxxxxxxxxxx>
To:     m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>, 
Date:   03/14/2013 04:57 AM
Subject:        Re: [m2m-iwg] Consumer device security (was: M3DA 
presentation)
Sent by:        m2m-iwg-bounces@xxxxxxxxxxx



Well I would concur to you analysis.
Actually, and sorry to bring it again on the table, M3DA security was 
designed with that in mind: being lightweight enough so that it can 
implemented on a small device. This create a lightweight link between a 
fleet of devices and a gate to the world (the server) that redispatch the 
data with a more traditional security approach (HTTP, TLS, etc.)
M3DA security involves hashes (MD5 or SHA1) and a cipher (AES) that are 
light enough but still recognize as of good quality cryptography.
 
In addition to that if AES is too much for your device and/or you only 
need to sign your data, you can activate authentication only! (encryption 
is optional). Authentication only requires only a hash function (as it 
uses HMAC to authenticate). That effectively sign your data at a very 
cheap resource cost.
 
De : m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] De 
la part de T-Rob
Envoyé : mercredi 13 mars 2013 19:17
À : m2m Industry Working Group
Objet : [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 wrote on 03/13/2013 07:25:47 AM:

> From: Fabien Fleutot <fleutot@xxxxxxxxx> 
> To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>, 
> Date: 03/13/2013 07:26 AM 
> Subject: Re: [m2m-iwg] M3DA presentation - Security 
> Sent by: 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
> http://dev.eclipse.org/mailman/listinfo/m2m-iwg
_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg