algorithm agility for IoT
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?
Hi, I'm not sure it's applicable, but mechanisms behind RIPE Atlas, when looked at as an IoT-like service, can also be considered as an example. I guess we can talk about the details offline. Regards, Robert On 2019-01-21 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
Hi all, In case others are interested in this, here is some more information about the considerations and principles that went into RIPE Atlas: 1. RIPE Atlas Probes as IoT Devices https://labs.ripe.net/Members/kistel/ripe-atlas-probes-as-iot-devices 2. RIPE Atlas Architecture - How We Manage Our Probes https://labs.ripe.net/Members/kistel/ripe-atlas-architecture-how-we- manage-our-probes Kind regards, Mirjam Kühne RIPE NCC On 21/01/2019 13:12, Robert Kisteleki wrote:
Hi,
I'm not sure it's applicable, but mechanisms behind RIPE Atlas, when looked at as an IoT-like service, can also be considered as an example.
I guess we can talk about the details offline.
Regards, Robert
On 2019-01-21 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
_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg
On 21 Jan 2019, at 12:12, Robert Kisteleki <robert@ripe.net> wrote:
I'm not sure it's applicable, but mechanisms behind RIPE Atlas, when looked at as an IoT-like service, can also be considered as an example.
I guess we can talk about the details offline.
Thanks Robert. And thanks Mirjam for the links!
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
Jim Reid <jim@rfc1035.com> 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. In general the current IoT "MUST" seems to be ECDHE-ECDSA-AES128-CCM8. (This is an AEAD, so AES128 is also the integrity protection) It has a slightly different name in TLS 1.3. Having only one for a small device is not unreasonable from a hardware point of view, but from a systemic point of view, it causes a flag day. A can not upgrade because B does not support it, so A does not add anything new and when B decides to upgrade, A does not support anything new. It appears that hardware that supports AES128-CCM8 also supports AES256-CCM8. That's a bit of an upgrade, but the only thing wrong with AES128 is that it's considered too small for the first Quantum attacks. Somehow AES256 is considered big enough to withstand things. (Don't ask me...) But if a Quantum Computer can break AES128, then it probably will have already broken ECDSA and ECDHE. The biggest concern with ECDSA is probably that it's usually deployed with the NIST P-256 (prime256v1/secp256k1). Some find this suspect, and thus we have other curves with different levels of trust. Then we have EdDSA and the IETF/IRTF/CFRG Curve448 and Curve25519. If we had to have an alternative to ECDHE-ECDSA-AES128-CCM8, having TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (https://tools.ietf.org/html/rfc7905 ) woudl be nice. Having two or three "backup" algorithms in the non-constrained side of the equation means that there can be innovation on the constrained side. This is what I would really like to have in a standards document. This matters to the hardware planners both on the constrained side of things, and also on the cloud side of things. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
participants (5)
-
Eliot Lear -
Jim Reid -
Michael Richardson -
Mirjam Kuehne -
Robert Kisteleki