Hi Hannes -
Basically, the argument I'm hearing again is that we have to have common
protocols that work with the least capable devices in the same way that
they work with more capable devices. Which then is taken to mean that
we have to limit the security of said protocols to what's available with
those most limited devices.
This seems to be a bad argument both for the big guys and for the small
guys. And its really not about the hardware requirements for a specific
device that should be the concern of the IETF, but about specifying the
protocol requirements - said requirements being reasonable for the
specific limited field of use.
E.g. The recommendation must be for a "good" RNG - that doesn't
necessarily translate to a requirement for a hardware TRNG, but if
that's what you need to get to "good", then that's what the builder
should spec.
I'm wondering if its time to fork the Internet Standards path and create
an IOT Standards RFC path that deals with these less capable devices,
explains that these are not to be used for larger devices unless talking
to the constrained devices, but which still gets the IETF standards
process treatment? RFC 7228 may have done us a disservice by not
explaining what the minimum capable security services were for each of
the classes.
Mike
On 5/14/2018 2:49 PM, Hannes Tschofenig wrote:
Here is my personal take on this: you have to do your threat assessment to find
out what attacks you care about. This will determine your hardware requirements
(not the other way around). At a minimum you will have to figure out how to
provide randomness in your design and that can come at a very low cost. For
example, if I use ST's MCU finder
http://www.st.com/en/development-tools/st-mcu-finder.html and search for
microcontrollers that have TRNG support then I get 410 results (only for STM
MCUs).
If you aim for devices that also provide ECC/RSA crypto in hardware +
tamper-resistant key storage then we will move past the RFC 7228-type of
constrained IoT device classes. You have can a look of what this means in
context of Arm IP:
https://developer.arm.com/products/system-ip/trustzone-security-ip
On a meta-level I have difficulties with the security design decisions made in
IETF IoT-related groups since they swing back and forth between the extremes in
pretty much no time. At the London IETF meeting I hear people talking about
drafting guidelines for the use of new crypto algorithms with IoT devices since
P256r1 and AES128-CCM is not good enough for them. At the same time I am having
a hard time convincing people that using an unauthenticated identifier is not
good for security.
Ciao
Hannes
-----Original Message-----
From: Ace [mailto:[email protected]] On Behalf Of Michael Richardson
Sent: 14 May 2018 16:54
To: [email protected]
Subject: Re: [Ace] EST over CoAP
Hannes Tschofenig <[email protected]> wrote:
> Regarding the randomness requirement and the energy consumption. We
> have been a bit advocate for adding hardware-based random numbers to
> devices since randomness is a basic requirement for most security
> protocols.
I think that this is the future, and I very much agree with you.
There seems to be a stock of older designs which have gone through other kinds
of validation (for instance, think about the engineering review of physical
cases and PCB design for electric metering).
My impression is that there is a desire to significantly update the security profile of
these devices (some of which are in the field already). What was deployed had poor
security, or had proprietary protocols and there is a desire to move it up to
"par".
The other thing I hear is that the crypto libraries involved take some time to
get FIPS-140 certified and so the one that the devices were deployed with do
RSA only, and there is a desire to update them to ECDSA (or EdDSA), and means
new keys.
I think that any device with any kind of TPM would rather generate it's own
keys. Whether it's a physical TPM, or some kind of TrustZone,etc. version.
> In a nutshell, I think you are better of recommending OEMs to select
> the right hardware for the given task.
I'd like to find some text that acknowledges the past, while setting things up
better for the future.
> PS: For the proxy work (in context of DTLS/TLS) you might want to reach
> out to your co-worker Owen Friel.
he's in other loops already, but he seems shy to post to lists.
> IMPORTANT NOTICE: The contents of this email and any attachments are
I wish your email system would omit this, as it's both meaningless and
sometimes harmful.
--
Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6
IoT consulting =-
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
