Subject: [saag] Performance of Crypto on IoT Devices

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Apr 2016 21:01:14 +0200

In response to a question from Bob Moskowitz at the SAAG meeting today I
mentioned performance investigations of crypto on IoT devices we have
been doing.

You can find a short write-up here:
http://www.tschofenig.priv.at/wp/?p=1091

I believe that the threat analysis should determine the choice of
security mechanism. Making sure that those security mechanisms actually
run on the hardware may require selecting a different hardware.
Depending on the threats that need to be addressed additional hardware
security features may be needed.

Ciao
Hannes

---

From: Mohit Sethi <[email-masked]>
Date: Thu, 7 Apr 2016 17:02:29 -0300

I would also like to point to the performance measurements of ECDSA 
signatures on 8-bit micro-controller devices which is documented in the 
LWIG draft found here:
https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-00

and the related research publication here:
https://www.researchgate.net/profile/Mohit_Sethi/publication/261334004_End-to-end_Security_for_Sleepy_Smart_Object_Networks/links/00b49533e6c566943b000000.pdf 
<https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/master/lightweight-crypto/lightweight-crypto.pdf>

Regards
Mohit

On 04/07/2016 04:01 PM, Hannes Tschofenig wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Apr 2016 22:10:31 +0200

Mohit,

unfortunately your results on 8-bit MCUs confirm what Bob had been
complaining about at the SAAG meeting.

Ciao
Hannes

On 04/07/2016 10:02 PM, Mohit Sethi wrote:
> <https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-00>https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-00
> 
> <https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/master/lightweight-crypto/lightweight-crypto.pdf>https://www.researchgate.net/profile/Mohit_Sethi/publication/261334004_End-to-end_Security_for_Sleepy_Smart_Object_Networks/links/00b49533e6c566943b000000.pdf
> 
> Regards
> Mohit
>

---

From: Mohit Sethi <[email-masked]>
Date: Thu, 7 Apr 2016 17:16:36 -0300

Please have a closer look at the Table 5 in the draft. Is ECDSA signing 
with NIST K163 in 261 ms and in less than ~2900 bytes of memory not good 
enough for you? Bear in mind I am using an existing generic crypto library.

Regards
Mohit

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 8 Apr 2016 07:47:55 +0000

Mohit Sethi <[email-masked]> writes:

>Please have a closer look at the Table 5 in the draft. Is ECDSA signing with
>NIST K163 in 261 ms and in less than ~2900 bytes of memory not good enough for
>you? 

Dunno, how well does it run TLS?  Doing one particular operation isn't that
hard (I'm pretty sure I can get something going on a 6502 if you paid me
enough), but what matters is whether you can use it as part of something
useful.

Peter.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 8 Apr 2016 09:46:08 +0000

For those who weren't in the meeting, could you summarise (or give a pointer to) what Bob was complaining about. Thanks.

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: saag [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: 07 April 2016 21:11
To: Mohit Sethi; saag
Subject: Re: [saag] Performance of Crypto on IoT Devices

Mohit,

unfortunately your results on 8-bit MCUs confirm what Bob had been complaining about at the SAAG meeting.

Ciao
Hannes

On 04/07/2016 10:02 PM, Mohit Sethi wrote:
> signatures on 8-bit micro-controller devices which is documented in 
> the LWIG draft found here:
> <https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-00>https://
> tools.ietf.org/html/draft-aks-lwig-crypto-sensors-00
> 
> <https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/mas
> ter/lightweight-crypto/lightweight-crypto.pdf>https://www.researchgate
> .net/profile/Mohit_Sethi/publication/261334004_End-to-end_Security_for
> _Sleepy_Smart_Object_Networks/links/00b49533e6c566943b000000.pdf
> 
> Regards
> Mohit
> 
>> In response to a question from Bob Moskowitz at the SAAG meeting 
>> today I mentioned performance investigations of crypto on IoT devices 
>> we have been doing.
>>
>> security mechanism. Making sure that those security mechanisms 
>> actually run on the hardware may require selecting a different hardware.
>> Depending on the threats that need to be addressed additional 
>> hardware security features may be needed.
>>
>> Ciao
>> Hannes
>>
>>
>>

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Apr 2016 07:48:37 -0300

Bob complained that ECC operations took so long on some of those 8-bit processors that are being put into the “things” that such crypto becomes impractical. He was talking about EC operations taking “minutes”.

Yoav

> On 8 Apr 2016, at 6:46 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 8 Apr 2016 10:03:20 -0300

Well, for the vendor I worked with, it was 9s for EC25519 to do the ECDH 
operation to derive the master key.  They switched to BLAKE2 over what 
they had for their hash, after I showed papers on attacks.

Now talk to the BacNet people that have FOUR bit processors and what 
they have done to even implement AES.

I expect to be hitting similar issues with CanBUS-FM (at least 64 byte 
MPDU).

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 8 Apr 2016 10:19:10 -0300

Another aspect of this is the hit on the battery for the ECDH 
operation.  With it only occuring at network join time, they can live 
with it.  Regular use would significantly shorten their use life.

On 04/08/2016 10:03 AM, Robert Moskowitz wrote:
> Well, for the vendor I worked with, it was 9s for EC25519 to do the 
> ECDH operation to derive the master key.  They switched to BLAKE2 over 
> what they had for their hash, after I showed papers on attacks.
>
>> Bob complained that ECC operations took so long on some of those 
>> 8-bit processors that are being put into the “things” that such 
>> crypto becomes impractical. He was talking about EC operations taking 
>> “minutes”.
>>
>> Yoav
>>
>>> For those who weren't in the meeting, could you summarise (or give a 
>>> pointer to) what Bob was complaining about. Thanks.
>>>
>>> -- 
>>> Christopher Dearlove

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Apr 2016 10:29:07 -0300

Quite a few protocols (TLS, IKE) have the ability to perform the DH operation once and then either keep keys for a long time, or rekey cheaply with some stored state.

And yes, this does require offline storage of several dozen bytes, which may or may not be an issue.

Yoav

> On 8 Apr 2016, at 10:19 AM, Robert Moskowitz <[email-masked]> wrote:
> 
> Another aspect of this is the hit on the battery for the ECDH operation.  With it only occuring at network join time, they can live with it.  Regular use would significantly shorten their use life.
> 
>> Well, for the vendor I worked with, it was 9s for EC25519 to do the ECDH operation to derive the master key.  They switched to BLAKE2 over what they had for their hash, after I showed papers on attacks.
>> 
>> Now talk to the BacNet people that have FOUR bit processors and what they have done to even implement AES.
>> 
>> I expect to be hitting similar issues with CanBUS-FM (at least 64 byte MPDU).
>>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 8 Apr 2016 11:07:03 -0300

ECDH was the only crypto other than AES CCM that they could implement.

There are protocols that only do ECDH; those that are not SIGMA 
compliant.  I always am on the lookout for staying with standards. But 
come on down to really small stuff; it is interesting.

---

From: Mohit Sethi <[email-masked]>
Date: Fri, 8 Apr 2016 11:09:27 -0300

Dear Peter

I absolutely agree with you.

In section 9 of the draft [1], we discuss an example application 
scenario where ECDSA use would make sense. The idea was to allow 
constrained sensors to sleep most of the time and wake up periodically 
to send signed updates to a proxy. The proxy and other interested client 
applications can then verify signatures for integrity assurance of the 
recorded sensor values. We implemented this whole scenario with an 
optimized implementation of the Constrained Application Protocol (CoAP) 
on the same board. Table 8 provides the memory and execution times for 
the entire application.

[1] https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-00

Regards
Mohit

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Apr 2016 14:13:13 +0000

You know, it takes me an awful long time to do X25519 using my abacus, too. 

Four-bit processors can't do modern crypto?  Eight-bit can't?  Quell surprise

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 8 Apr 2016 11:21:56 -0300

> You know, it takes me an awful long time to do X25519 using my abacus, too.

And you are probably faster at it than me!

> Four-bit processors can't do modern crypto?  Eight-bit can't?  Quell surprise
I am looking at symmetric solutions for 4 bit.  They got ECDH working on 
a very contrained 8 bit.  I don't see memory/battery constrained devices 
doing more than that.

But I am open to pointers of successful work.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Apr 2016 11:22:32 -0300

So the big issue is that you have a lightbulb or a thermometer. They don’t need a lot of computing. They receive messages like “on” or “off”, and send messages like “23” or “error”.

A 4-bit processor is plenty powerful enough to process some CoAP or proprietary protocol message that carries such messages. The only reason to have a more powerful processor is the crypto.

This is nothing like regular computing. If we didn’t need any crypto, our laptops and phones would be as powerful as they are now. A browser takes as much power to render modern HTML and Javascript as it does to encrypt that HTML and Javascript. Probably more. Web servers need more power to transition from HTTP to HTTPS, but it’s not like it doubles the power requirements, let alone require a processor that is 100x more powerful.

So we’re significantly increasing power requirements and cost if we demand modern crypto.

Yoav

> On 8 Apr 2016, at 11:13 AM, Salz, Rich <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 08 Apr 2016 13:04:01 -0300

> So we’re significantly increasing power requirements and cost if we demand modern crypto.

Yes.

There is a minimum requirement for a node to be a citizen on the
Internet.  In RFC 7228, we tried to capture some of this thinking.

The question really is what burden we impose as a minimal requirement
for those nodes.

Clearly, asymmetric crypto *can* be performed on 8-bit CPUs.  Mohit's
data show that, and it's even better with modern curves and
implementations (e.g., see http://munacl.cryptojedi.org).  If we need to
discuss this further, we should use accepted curves, current devices
[not necessarily brand-new, but devices you would put into a new
design], and current crypto implementations.  But in any case, the cost
of asymmetric crypto will rarely be completely ignorable.

The question is whether you *want* to require asymmetric crypto for some
protocol, and what specific applications you use it for.  Please see
https://jafrum.files.wordpress.com/2013/09/sofa-motorcycle-overloaded.jpg
for an illustration that you may not always *want to* do what you *can* do.

One approach is to never *require* asymmetric crypto.
However, there are some total cost of ownership advantages to asymmetric
crypto in certain deployment scenarios.  To capture those, your toolkit
should probably provide options to be *able* to use asymmetric crypto at
least for:

[x] initial enrollment and key agreement
[x] regular rekeying (as in yearly or monthly)

You may want to be able to stick to symmetric crypto for:

[_] Connection setup, IP address updates, etc.
[_] Per-operation, per-message crypto
[_] Anything that an attacker can make you do

Of course, there are different views on this.  Actually, the ability to
perform asymmetric crypto well is a major selling point for the 32-bit
CPUs that companies such as Hannes' employer create.

Also, there may be additional application requirements such as
third-party verifiability (which used to be called "non-repudation" in
some circles) where asymmetric crypto comes in handy.

IoT Devices often have a longer lifetime than smartphones.  This leads
to having to consider the threat of quantum computers, which leave
traditional asymmetric crypto vulnerable, while symmetric crypto mostly
survives (maybe after adjusting up some key sizes).

Some of the ways we "enhance" operations by asymmetric crypto mean that
you have no security left at all in a post-quantum (PQ) world, even
though the enhancement just was meant to add a property such as forward
security to a situation that could otherwise easily be PQ-secure.  We
need to be more careful about this.

So my summary of the situation is:

-- Don't require asymmetric crypto to be available on all IoT devices.
-- Make good use of asymmetric crypto when you have it or need it.
-- Make sure that you have some security left in a PQ world.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Apr 2016 15:38:47 -0400

Yoav Nir <[email-masked]> wrote:
    > A 4-bit processor is plenty powerful enough to process some CoAP or
    > proprietary protocol message that carries such messages. The only
    > reason to have a more powerful processor is the crypto.

I think you misstate this to blame the messager (literally).
The crypto is a means to an end.

"A 4-bit processor is plenty powerful enough to process some CoAP or
proprietary protocol message that carries such messages. The only reason to
have a more powerful processor is because you would like access control
on the device. "

    > So we’re significantly increasing power requirements and cost if we demand modern crypto.

It's not the crypto, it the networking.
Remove the network, and you don't need security.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Apr 2016 18:32:01 -0300

There is no”blame” here. But I can understand the reluctance to quadruple or more the component cost.

Sent from my Windows 10 phone

From: Michael Richardson
Sent: Friday, April 8, 2016 16:39
To: Security Area Advisory Group
Subject: Re: [saag] Performance of Crypto on IoT Devices