Jim, I think it's probably worth looking at this from the perspectives of performance and time wrt IOT. Re performance, as there are a lot of time critical ops that take place in IoT devices, something that tweeks the performance of a device can do damage. Engineering to avoid that might cost a few bucks. In some cases that might be worth it. It depends on the criticality and life cycle of the box. I don't think we'll see this for short lived sensors, if we see any security at all, but a box you drop into the ground for 40 years? You probably want to leave a little growing room in terms of meeting the requirements. A good test is if you can meet performance requirements using two current crypto suites that have good security properties and then adding a little extra room. But it's not easy, and that's $$. Sometimes mega-$$ to accomplish. Eliot On 21.01.19 12:54, Jim Reid wrote:
I’m working on a document at ITU Study Group 20 on algorithm agility. [So you don’t have to! :-)] The aim is to produce a Recommendation which essentially says “don’t hard-wire crypto algorithms into IoT stuff because what’s secure today could be insecure tomorrow”. For instance, building or deploying an IoT solution that can’t use anything but MD5 or DES (say) would be bad. Similarly, it would be undesirable to install a sensor network today that can’t handle tomorrow's devices because they might well use new crypto which isn’t around today.
At the moment, the document cites the mechanisms used in TLS and DNSSEC as frameworks that those deploying and designing IoT infrastructure should consider. ie Continuously updated registries which add new algorithms when these become available and drop old ones which are considered unsafe or whatever. Please note that the document isn’t going to say everyone *must* use TLS and/or DNSSEC since that clearly depends on specific (unique?) use cases and requirements. Instead the document will say that people should take account of those sorts of frameworks when they are designing, procuring or operating IoT infrastructure.
SG20 has said the document needs more examples of these kinds of frameworks. So I’m asking the list if they can suggest some. I’d particularly like to about potential examples from those developing IoT firmware or operating systems. Or authentication schemes for IoT. What sort of mechanisms and frameworks are available? What’s done in RIOT or the stripped down BSD/Linux stuff that underpins some IoT platforms? Anything else?
The obvious example that springs to mind are dynamic SSL libraries - for instance the package managers that supply the latest version(s) of OpenSSL. Or the replacements for that which sprung up after the Heartbleed incident. However that’s a bit fuzzy. I suppose CAB Forum advice on X.509 certificates might be another.
But there must be more. Any suggestions or pointers?
_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg