[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2m-iwg] Consumer device security (was: M3DA presentation)
|
I think the other important question to ask instead is whether this is indeed an optimal connected device model (each device connected directly) or does it make more sense to leverage a more intelligent "gateway" that can deal with a higher degree of security (read: more capability required to implement it) than a "dumb" device on a local, isolated network...
-----Original Message-----
From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On Behalf Of T-Rob
Sent: Monday, March 18, 2013 12:17 PM
To: m2m Industry Working Group
Cc: m2m-iwg-bounces@xxxxxxxxxxx
Subject: Re: [m2m-iwg] Consumer device security (was: M3DA presentation)
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
_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
