Re: [iot-wg] algorithm agility for IoT
On 21 Jan 2019, at 12:36, Andrei Kolesnikov <andrei@rol.ru> wrote:
Consider this problem of "hard wired crypto" only for specific class of IoT devices: power hungry, long-live, manageable, internet connected. The similarity must be with any user premises equipment, such as wifi routers, cameras, etc.
I’m not sure that’s true Andrei. If an IoT device is on the Internet, it shouldn’t have hard-wired crypto. Just like how it shouldn’t have a factory-set password of 0000 or whatever. This should not be a subject for debate. It’s basic common sense.* Whether that device is a node in a sensor network or some piece of CPE is irrelevant from that perspective. Of course there are lots of trade-offs to be made when selecting crypto solutions for IoT: device lifetime, power, key lengths & rotation capabilities, memory & CPU capacity, bandwidth, costs, etc, prevailing policy & legislation, etc. But that’s an entirely different discussion which is orthogonal to the matter at hand. * It’s such basic common sense it isn’t written down anywhere. As least I’ve not been able to find it in a standards document yet. Which means that common sense can’t get baked into equipment procurements, RFPs and so on. So if there’s an RFC or ITU Recommendation or whatever along those lines...
On 21 Jan 2019, at 13:53, Jim Reid <jim@rfc1035.com> wrote:
I’m not sure that’s true Andrei.
If an IoT device is on the Internet, it shouldn’t have hard-wired crypto. Just like how it shouldn’t have a factory-set password of 0000 or whatever. This should not be a subject for debate. It’s basic common sense.* Whether that device is a node in a sensor network or some piece of CPE is irrelevant from that perspective.
A bit to the side of this, but probably relevant in this context: the ongoing discussion between “hardware based security” and “software”. This also flairs up every now and then in forums like AIOTI. Where chip vendors of course are a big proponent of hardware based solutions, saying software is easier to compromise. Agility as you propose doesn’t rule out hardware solutions, but they are probably harder to modify on-the-go and less agile as an entirely software based solution. I have no particular opinion on it, but pushing back on hardware solutions may find some responding counter pressure from those groups who prefer hardware over software. On the original question; did you already look at GSM’s eSIM (and possibly SIM) specification. Not 100% sure they are ‘agile’ in a sense you are aiming for, but it has some ways to update to newer stuff afaik. MarcoH
On 21 Jan 2019, at 13:22, Marco Hogewoning <marcoh@ripe.net> wrote:
Agility as you propose doesn’t rule out hardware solutions, but they are probably harder to modify on-the-go and less agile as an entirely software based solution.
Thanks for that clarification Marco. For the avoidance of doubt, I was *NOT* talking about hardware when I mentioned "hard-wired crypto”. Though the term could include that. Crypto done in software would be hard wired if that software couldn’t be changed. For instance if it was burnt into ROM or the vendor couldn’t be bothered to provide some way for the software to be updated or reconfigured whenever the crypto landscape moved.
Hi Jim,
On 21 Jan 2019, at 12:53, Jim Reid <jim@rfc1035.com> wrote:
* It’s such basic common sense it isn’t written down anywhere. As least I’ve not been able to find it in a standards document yet. Which means that common sense can’t get baked into equipment procurements, RFPs and so on. So if there’s an RFC or ITU Recommendation or whatever along those lines...
On 21 Jan 2019, at 13:29, Mat Ford <ford@isoc.org> wrote:
Hi Jim,
On 21 Jan 2019, at 12:53, Jim Reid <jim@rfc1035.com> wrote:
* It’s such basic common sense it isn’t written down anywhere. As least I’ve not been able to find it in a standards document yet. Which means that common sense can’t get baked into equipment procurements, RFPs and so on. So if there’s an RFC or ITU Recommendation or whatever along those lines...
Thanks Mat. RFC7696 is mostly about the trade-offs and implementation choices. It has lots of great advice. However it’s not quite on target. Which is about trying to ensure IoT platforms have the frameworks to support diverse implementation choices. And of course those choices almost certainly will change over time as new algorithms emerge and old ones get killed. ie It’s about how to facilitate those choices, not the choices themselves. If you consider RFC7696 as a meta-discussion on making those choices, I’m aiming at a meta-meta discussion about how IoT platforms can enable things like RFC7696-based decision making.
participants (3)
-
Jim Reid -
Marco Hogewoning -
Mat Ford