Subject: Re: [Cfrg] [TLS] 3DES diediedie

From: Joachim Strömbergson <[email-masked]>
Date: Thu, 01 Sep 2016 09:50:15 +0200

Aloha!

Hilarie Orman wrote:
> An ARM is far too much hardware to throw at "read sensor/munge
> data/send data".

No, they are not. The Cortex M0+ is aimed at these kinds of very simple
systems that runs for many years on a single battery.

Look at the STM32L0 series from ST for example. These devices can run on
energy harvesting and very tiny physically and very, very cheap (ten-ish
cents in high volume):

http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32l0-series.html?querycriteria=productId=SS1817

The STM32L021 has an AES-128 core. Not very fast (200+ cycles), but
several times faster than SW. You can also run the AES core wile the CPU
core is in power save mode.

Another example is the Zero Gecko from Silicon Labs. Same price range, a
huge number of power modes. And an AES core that is really fast. 50+
cycles for AES-128, which basically means 4 cycles/round (which implies
4 S-boxes)

https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx

Pre-shared key is whats easiest. But I've implemented Curve25519 for key
exchange on the STM32 device and can achieve <1 sec performance with
about 1 kByte RAM and 8 kByte code. I'm sure Peter Schwabe has some much
better results.

Yes, you can limit yourself to an 8-bit MCU and shave off some cents and
a little bit of power. But for most applications I see, a Cortex M0+
meets technical and commercial requirements too.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          [email-masked]
========================================================================

---

From: "Hilarie Orman" <[email-masked]>
Date: Thu, 1 Sep 2016 10:17:59 -0600

>  Aloha!

Aloha auinala.

>  https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx

For devices you refer to, how many AES blocks can they encrypt on a AA
battery, assuming that the usage is to encrypt one block every 10 minutes?

Hilarie

---

From: Joachim Strömbergson <[email-masked]>
Date: Thu, 01 Sep 2016 19:57:23 +0200

Aloha!

Hilarie Orman wrote:
> For devices you refer to, how many AES blocks can they encrypt on a
> AA battery, assuming that the usage is to encrypt one block every 10
> minutes?

That is actually a very interesting, but hard question to answer. Will
the MCU be doing anything else in between? What kind of I/O will the
resulting block be sent over? The AES core itself can be switched off
from power on a single cycle

What I have seen is projects where one of those devices are being used
to send data at about that rate (AES-CTR encrypted) powered by a small
cell battery with a lifespan of at least 8 years. It does very little in
between though. Rough calculation gives 420k events, but each message
generated by an event is larger than a single AES block.

One thing to note is that 8-bit MCUs are commonly manufactured in older
chip processes with bigger transistors and power hungry I/Os, less power
modes than these newer ARM devices.

- --

---

From: Ben Laurie <[email-masked]>
Date: Mon, 5 Sep 2016 19:25:39 +0100

On 31 August 2016 at 20:48, Hilarie Orman <[email-masked]> wrote:

> >  From: Brian Sniffen <[email-masked]>
>
> >  >>  From: Derek Atkins <[email-masked]>
> >  >>  Date: Wed, 31 Aug 2016 10:17:25 -0400
> >  >
> >  >>  "Steven M. Bellovin" <[email-masked]> writes:
> >  >
> >  >>  > Yes.  To a large extent, the "IoT devices are too puny for real
> >  >>  > crypto" is a hangover from several years ago. It was once true;
> for
> >  >>  > the most part, it isn't today, but people haven't flushed their
> cache
> >  >>  > from the old received wisdom.
> >  >
> >  >>  This is certainly true for AES, mostly because many small chips are
> >  >>  including AES accelerators in hardware.  It's not quite true for
> public
> >  >>  key solutions; there are still very small devices where even ECC
> takes
> >  >>  too long (and yes, there are cases where 200-400ms is still too
> long).
> >  >
> >  >>  > It pays to look again at David Wagner's slides from 2005, on
> sensor
> >  >>  > nets and crypto:
> >  >>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
> >  >>  >
> >  >
> >  > Unattended sensors with wifi present an unsolved crypto problem.  They
> >  > can last 10 years on an AA battery without crypto, probably well less
> >  > than a year if they have to do any kind of encryption.  These things
> >  > will be everywhere, providing the data that will underly all kinds of
> >  > decision-making.
>
> >  Assuming there are *some* integrity requirements for the data, and that
> >  they are deploying 32-bit ARM with AES support (stipulating that ~every
> >  CPU will have AES support in a few years, as ~every CPU sold does
> >  today), we're talking about *either* an ECDHE negotiation every few
> >  months or a pre-shared key, good for ten years.
>
> >  AES-GCM with hardware support compares favorably to SHA-2 without
> >  hardware support, so if they've been able to last 10 years before, they
> >  should do just fine in the future.  The old devices won't last forever,
> >  and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us
> >  for ten years after 1.3 is out.
>
> >  -Brian
>
> >  > Although much of the solution may lie in hardware innovation, the
> >  > world really does need minimal crypto algorithms.
> >  >
> >  > Hilarie
> >  >
>
> An ARM is far too much hardware to throw at "read sensor/munge data/send
> data".
>

The question is not "how much hardware?" but "price?" - with  ARMs
including h/w AES coming in at $2 for a single unit, its hard to explain
why you\d want to use a less powerful CPU...

>
> Hilarie
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 5 Sep 2016 13:06:45 -0600

>  > Hilarie

Power.

Hilarie

---

From: Ben Laurie <[email-masked]>
Date: Mon, 5 Sep 2016 21:44:50 +0100

On 5 September 2016 at 20:06, Hilarie Orman <[email-masked]> wrote:
> At some time when attribution was hard, I wrote:

AIUI the main power sink is comms.

---

From: Joachim Strömbergson <[email-masked]>
Date: Tue, 06 Sep 2016 08:36:25 +0200

Aloha!

Hilarie Orman wrote:
>> including h/w AES coming in at $2 for a single unit, its hard to
>> explain why you\d want to use a less powerful CPU...
> 
> 
> Power.
> 
> Hilarie

Did you look at the ARM Cortex M0+ Gecko Zero I pointed to? I'd
recommend that you compare its power consumption to a PIC.

The PIC is manufactured using larger geometries that consumes more
power/gate/MHz. The Gecko Zero has more power modes allowing it to
enable/disable different functions very fast, and is able to scale its
own internal clock frequency very flexibly. The Gecko Zero (and other
M0+ devices) can also do more/cycle so that total power up time is
shortened, saving power.

Specifically (since we talked about it before), the AES core in the
Gecko Zero takes about 50 cycles to process one block (and the CPU core
can be powered down at the same time). Googling for cycles to perform
AES on PIC I found:

Encryption
PIC16F877 : 3834 cycles
PIC16F84 : 7157 cycles

https://edipermadi.wordpress.com/2008/02/09/an-aes-implementation-on-pic16f877/

So on the PIC you need to have the CPU core powered up and running about
80 times longer (in terms of cycles) than the Gecko needs to run its AES
core.

And even if you don't have an AES core, the ARM can do AES in fewer
cycles. This one shows 2270 cycles for AES-128

http://www.cryptovia.com/ARM_Thumb_AES.html

Selecting 8/16 bit MCUs like AVR, PIC, 8051 in 2016 for power reasons
without looking at modern 32-bit MCUs based on ARM or MIPS is a mistake
imho.

- --

---

From: Derek Atkins <[email-masked]>
Date: Tue, 06 Sep 2016 16:40:30 -0400

Ben Laurie <[email-masked]> writes:

> The question is not "how much hardware?" but "price?" - with  ARMs including h
> /w AES coming in at $2 for a single unit, its hard to explain why you\d want
> to use a less powerful CPU...

Because this is a light bulb that sells for $6-10.  Adding $2 to the price
is just completely unreasonable.  The price point needs to be pennies.
Note that this is just one example, but yes, these level of products are
getting "smarter" and we, as security professionals, should encourage
"as strong security as possble" without getting the manufacturers to
just say "sorry, too expensive, I'll go without."  (which is,
unfortunately, exactly what's been happening)

>     Hilarie

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Dave Garrett <[email-masked]>
Date: Tue, 6 Sep 2016 20:17:29 -0400

> unfortunately, exactly what's been happening)

Personally, I'd just say "stop putting chips in light bulbs", instead. Companies making these things are unfortunately just not going to be making good security decisions. Bad or no security is cheaper than competent security, and selling light bulbs with bad security is not illegal. We'll be more successful focusing our effort on dealing with light bulb botnets than trying to get people to make secure "smart" light bulbs. There is no good solution on our end, and debating the price of chips for light bulbs is not a good way to make security decisions in TLS.

Dave

---

From: Ira McDonald <[email-masked]>
Date: Tue, 6 Sep 2016 20:28:13 -0400

Hi Dave,

Might work for lightbulbs.  Doesn't work for automotive sensors and ECUs,
which already have proprietary security (undisclosed algorithms) and badly
need to have standards-based security.  Cents in cost really matter here.
ARM CPUs are not and will not become the only answer in automotive.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Tue, Sep 6, 2016 at 8:17 PM, Dave Garrett <[email-masked]> wrote:

> data/send
> including h
> Personally, I'd just say "stop putting chips in light bulbs", instead.
> Companies making these things are unfortunately just not going to be making
> good security decisions. Bad or no security is cheaper than competent
> security, and selling light bulbs with bad security is not illegal. We'll
> be more successful focusing our effort on dealing with light bulb botnets
> than trying to get people to make secure "smart" light bulbs. There is no
> good solution on our end, and debating the price of chips for light bulbs
> is not a good way to make security decisions in TLS.
>
>
> Dave
>
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Philip Levis <[email-masked]>
Date: Tue, 6 Sep 2016 17:32:02 -0700

The market is moving to ARM Cortex Ms, in part because of their clean I/O architecture and good SoC support. An M0 with integrated BLE chipset is easily <1$ today at small scale. Extrapolate a few years and to volume of millions between large companies rather than small startups.  Software like mBed OS and 6lowpan support helps too. 

You or I might not want chips in our light bulbs, but some people will, and so it is part of the Internet landscape we need to keep in mind. 

Phil [sent from a phone]

> On Sep 6, 2016, at 5:17 PM, Dave Garrett <[email-masked]> wrote:
>

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 7 Sep 2016 04:15:05 +0000

OK, so I said I'd get some notes on the environment within which IoT crypto
has to function, here's what the peanut gallery came up with.  A lot of this
isn't my own work and I don't claim it to be, it's a collaboration created by
people who for various business/legal reasons can't attach their names to
public comments.  Note that every one of the for-instances given below are
actual real-life examples, not something someone invented to make a good
story.

Peter.

IoT Crypto, What you Need to Know
---------------------------------

  The problem we have is not how to get stronger crypto in place, it's how to
  get more crypto in place.
    -- Ian Grigg, 28 August 2016.

  ... and to raise the level of security of the rest of the system so that
  attackers are actually forced to target the crypto rather than just
  strolling around it.
    -- Peter Gutmann, in corollary.

The device may be operating under severe power constraints.  There are IoT
devices that need to run for several years on a single battery pack.  If
you're lucky, it's a bundle of 18650s.  If you're less lucky, it's a CR2032.

Renegotiating protocol state on every wake event is incompatible with low
power consumption.  The crypto should be able to resume from a pause an
arbitrary amount of time later.

Even if the device is constantly powered, many components will be powered only
when needed, and will lose state when powered off (they work by warm-starting
very quickly rather than saving state across restarts).

Some IoT chips can't cost more than a few cents each.  If you're lucky,
they're allowed to cost tens of cents.  Any fancy crypto hardware will break
the budget.

When crypto hardware support is available, it's universally AES, occasionally
SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA (there are also
oddballs like ones that do SHA-1 but not AES, but they're pretty special
cases, and AES in software is very efficient in any case).  Any crypto had
therefore better be based mostly, or exclusively, around AES.  As a convenient
side-effect of this, you won't have to worry about which flavour of PKC will
be in fashion in ten years' time, or what keysize they're wearing in Paris
that year.

Even if the device includes crypto hardware, the HAL or vendor-supplied
firmware may not make it available.  In addition the crypto engine will be in
a separate IP core that's effectively an external peripheral, and accessing it
is so painful that it's quicker to do it in software (you never get AES
instructions, you get something that you talk to via PIO).  As a result you
have to run your crypto in software while the crypto hardware sits idle.

Devices have a design lifetime of ten to twenty years, possibly more.  There
is hardware deployed today that was designed when the people now maintaining
it were in kindergarten.

Firmware is never updated, and frequently *can* never be updated.  This is
typically because it's not writeable, or there's no room (the code already
occupies 120% of available storage, brought down to 100% by replacing the
certificate-handling code with a memcpy() for encoding and a seek + read of {
n, e } for decoding, see below), leaving 0% available for firmware updates.
Alternatively, there's no connectivity to anything to provide updates, either
of firmware or anything else (for example in one globally-deployed system the
CRL arrives once every 6-12 months via sneakernet, although I'm not sure why
they use CRLs since they can just disable the certificate or device
centrally).  Or the device, once approved and operational, can't ever be
changed.  Like children, make one mistake here and you have to live with it
for the next 15-20 years.

Even if the hardware and/or firmware could be updated, the rest of the
infrastructure often can't.  Some firmware needs to be built with a guaranteed
correspondence between the source code and the binary.  This means not only
using approved compilers from the late 1990s that cleanly translate the code
without using any tricks or fancy optimisations, but also scouring eBay for
the appropriate late-1990s hardware because it's not guaranteed that the
compiler running on current CPUs will produce the same result.

Don't bother asking "have you thought about using $shiny_new_thing from
$vendor" (or its closely-related overgeneralisation "Moore's Law means that
real soon now infinite CPU/memory/crypto will be available to anyone for
free").  They're already aware of $shiny_new_thing, $shiny_other_thing, and
$shiny_thing_you_havent_even_heard_of_yet, but aren't about to redo their
entire hardware design, software toolchain, BSP, system firmware,
certification, licensing, and product roadmap for any of them, no matter how
shiny they are.

The device may have no or only inadequate entropy sources.  Alternatively, if
there is an entropy source, it may lose state when it's powered off (see the
earlier comment on power management), requiring it to perform a time-consuming
entropy collection step before it can be used.  Since this can trigger the
watchdog (see the comment further down), it'll end up not being used.  Any
crypto protocol should therefore allow the entropy used in it to be injected
by both parties like TLS' client and server random values, because one party
may not have any entropy to inject.  In addition, it's best to prefer
algorithms that aren't dependent on high-quality randomness (ECDSA is a prime
example of something that fails catastrophically when there are problems with
randomness).

Many SoCs have different portions developed by different vendors, and the only
way to communicate between them is via predefined APIs.  If you need entropy
for your crypto and the entropy source is on a separate piece of IP that
doesn't provide an entropy-extraction interface, you either need to spend
twelve months negotiating access to the source, and pay handsomely for the
privilege, or do without.

(The following is a special case that only applies to very constrained
devices: As a variant of the above, there may be no accessible writeable non-
volatile memory on your section of the device.  Storing a seed for crypto keys
may work when you bake it into the firmware, but you can't update it once the
firmware is installed because there's no access to writeable nonvolatile
memory, unless you negotiate it with one of the vendors whose IP has access to
it).

Fuses are expensive and per-device provisioning is prohibitively expensive for
low-cost IoT chips.

As mentioned previously, certificates are handled by memcpy()ing a pre-encoded
certificate blob to the output and seeking to the appropriate location in an
incoming certificate and extracting { n, e } (note that that's { n, e }, not 
{ p, q, g, y } or { p, a, b, G, n, ... }).  If you've ever wondered why you
can feed a device an expired, digital-signature-only certificate and use it
for encryption, this is why (but see also the point on error handling below).
This is precisely what you get when you take a hardware spec targeted at
Cortex M0s, Coldfire's, AVRs, and MSP430s, and write a security spec that
requires the use of a PKI.

The whole device may be implemented as a single event-driven loop, with no
processes, threads, or different address spaces.  In addition there are hard
real-time constraints on processing.  You can't go off and do ECC or RSA or DH
and halt all other processing while you do so because the system watchdog will
hard-reset the CPU if you spend too long on something.  While it is possible,
with some effort, to write a manually-timesliced modmult implementation, the
result is horribly inefficient and a goldmine of timing channels.  It's also
painful to implement, and a specific implementation is completely tied to a
particular CPU architecture and clock speed.

MSP 430s.  Apologies to all the embedded devs who have just gone into
anaphylactic shock at the mention of that name.  There are billions of these
things in active use.  For a very recent one (August 2016), look at
http://www.ti.com/lit/ds/slase78a/slase78a.pdf.

Hardware-wise, a Raspberry Pi is a desktop PC, not an embedded device.  So is
an Alix APU, a BeagleBoard, a SheevaPlug, a CI20, a CubieBoard, a C.H.I.P, and
any number of similar things that people like to cite as examples of IoT
devices.

In general terms, errors are divided into two classes, recoverable and
nonrecoverable (this really is generalising a lot in order to avoid writing a
small essay).  Recoverable errors are typically handled by trying to find a
way to continue, possibly in slightly degraded form.  Non-recoverable errors
are typically handled by forcing a hard-fault, which restarts the system in a
known-good state.  For example one system that uses the event-loop model has,
sprinkled throughout the code, "if ( errType == FATAL ) while ( 55 );" (the 55
has no special significance, it's just a way to force an endless loop, which
causes the watchdog to reset the system).  An expired certificate or incorrect
key usage is a soft error for which the appropriate handling action is to
continue, so there's no point in even checking for it (see a previous point on
the lack of checking for this sort of thing).

(The equivalent in standard PCs - which includes tablets, phones, and other
devices - is to dump responsibility on the user, popping up a dialog that they
have to click past in order to continue, but at least now it's the user's
fault and not the developer's.  Embedded systems developers don't have the
luxury of doing this but have to explicitly manage these types of error
conditions themselves.  So when a protocol spec says SHOULD NOT or MUST NOT
then for standard PCs it means "throw up a warning/error dialog and blame the
user if they continue" and for embedded devices it means "continue if
possible".  Have you ever seen a security spec of any kind that tells you what
step to take next when a problem occurs?).

Development will be done by embedded systems engineers who are good at making
things work in tough environments but aren't crypto experts.  In addition,
portions of the device won't always work as they should.  Any crypto used had
better be able to take a huge amount of of abuse without failing.  AES-CBC,
even in the worst-case scenario of a constant, all-zero IV, at worst degrades
to AES-ECB.  AES-GCM (and related modes like AES-CTR), on the other hand, fail
completely for both confidentiality and integrity protection.  And you don't
even want to think about all the ways ECDSA can fail (see, for example, the
issues with entropy, and timing issues, above).

---

From: Joachim Strömbergson <[email-masked]>
Date: Wed, 07 Sep 2016 09:11:20 +0200

Aloha!

Derek Atkins wrote:
> Because this is a light bulb that sells for $6-10.  Adding $2 to the
> price is just completely unreasonable.  The price point needs to be
> pennies. Note that this is just one example, but yes, these level of
> products are getting "smarter" and we, as security professionals,
> should encourage "as strong security as possble" without getting the
> manufacturers to just say "sorry, too expensive, I'll go without."
> (which is, unfortunately, exactly what's been happening)

There are connected light bulbs and LEDs that contains ARM based MCUs on
the market today. Those MCUs costs less then 10 cents in high volume.

- --

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 7 Sep 2016 10:31:50 +0300

> for the next 15-20 years.

So one needs to do _really_ careful design (good luck with that, most
device design is utter garbage).

And also really careful implementation (good luck with that too).

Also, with 20 year time horizon from now, quantum computing is a serious
risk. Mostly concerns use of any asymmetric algorithms, since symmetric
algorithms should survive rather well[1].

> example of something that fails catastrophically when there are problems with

Lack of entropy is going to make things nasty. Especially with any sort of
asymmetric encryption or key exchange.

The TLS-style asymmetric designs don't come even close to cutting it if
client lacks good entropy source.

> requires the use of a PKI.

Use of PKI in many cases is just dumb idea, and even if you have case
where you need some form of PKI, X.509 is probably a bad idea to do it.
 
> any number of similar things that people like to cite as examples of IoT

Heck, I have seen board advertised for "IoT" applications where the
way I loaded new software was to transfer the C++11 source via either
USB stick or via TCP/IP over ethernet and then use GCC on the board
itself to make a binary...

Basically, if one can do that at all, it is pretty much sky is the limit
with the crypto...
 
> issues with entropy, and timing issues, above).

If you need symmetric encryption that can actually take abuse, you need
MRAE (heck, the M and R is pretty much synonym for can cope with serious
abuse).

[1] Even the algorithms that would have sub-par "security levels" are
likely formidable challenge to attack, even with quantum computer, due
to make-or-break-attack factors ignored by such simplistic analysis.

-Ilari

---

From: Richard Hartmann <[email-masked]>
Date: Wed, 7 Sep 2016 10:59:20 +0200

On Wed, Sep 7, 2016 at 6:15 AM, Peter Gutmann <[email-masked]> wrote:
> [a lot of really interesting stuff]

Thanks for the write-up. To focus what you wrote back on the thread at hand:

Is it correct when I say that the embedded programmers you talked to
don't care about any form of DES as they need/must/prefer to do AES,
anyway?

If yes, there's no reason in the embedded world that would prevent a diediedie.

Richard

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 7 Sep 2016 10:38:35 +0000

>client lacks good entropy source.

Actually they're fine, see the comment about using entropy from both sides.
You can run one side of a TLS communication with zero entropy (just a fixed
secret) if you mix the client and server hello into your PRNG alongside the
fixed secret data.

>Heck, I have seen board advertised for "IoT" applications where the way I
>loaded new software was to transfer the C++11 source via either USB stick or
>via TCP/IP over ethernet and then use GCC on the board itself to make a
>binary...

That's how you do development work for the CI20.  It's actually rather
convenient, you just plug it in, SSH over, and you're ready to go.

Maybe that's one way to identify whether your "IoT device" falls into the
desktop-PC equivalent class, if it can self-host its own build tools it's a
PC.  If you upload a single solid blob that's the BSP/OS and application all
in one over a serial port and debug it using whatever cavemen used to debug
fire then it's embedded/IoT/SCADA/whatever.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Sep 2016 12:17:10 +0000

Perhaps a way forward here is for someone to document a target platform.  Or multiple target platforms, and decide which are in-scope and out of scope for us to look at.

Arguing by anecdote -- this lightbulb has this 10-cent part, that car has this ARM supercore with gigs of memory -- just gets us going around and around in circles.

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 7 Sep 2016 12:45:14 -0700

On Tue, Sep 6, 2016 at 9:15 PM, Peter Gutmann <[email-masked]>
wrote:

> SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA

EMV chip cards support RSA digital signatures. Granted earlier EMV cards
used ridiculously small key lengths (i.e. 320-bits), but they have been
gradually ratcheted up to e.g. 768 or 1024-bits.

These cards number in the billions (10s of billions?) and the chips are
priced in the penny range.

I don't think it's impractical to ship hardware accelerated asymmetric
crypto primitives on chips that meet the specifications you're describing.
The payments industry has definitely shown it's possible.

-- 
Tony Arcieri

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 8 Sep 2016 05:53:29 +0000

Richard Hartmann <[email-masked]> writes:

>Is it correct when I say that the embedded programmers you talked to don't 
>care about any form of DES as they need/must/prefer to do AES, anyway?

The only data point I have is that every time I've tried to disable DES in
a new release (and by DES I mean single DES, not 3DES) I've had a chorus of 
complaints about it vanishing.  Unfortunately I don't have anything more
than that, you only find out about things like this when they break stuff.
Certainly DES still sees a surprising amount of use, and in many cases it's
quite justified, whatever you're protecting is adequately safeguarded with
DES.  For example burglar alarms, if they use real encryption (far too many
use "encryption" that would more accurately be described as data masking),
often use DES, no doubt based on Microchip App Note 583 or freely available
source like despiccable, which runs in 20 bytes of RAM (if your burglar alarm
is advertised as having a "RISC based CPU" then it's probably using a PIC,
having a processor so spartan it can barely add is now a marketing feature if
you use the right name for it).  They'll be using DES forever, because the 
entire environment they operate in runs DES.

>If yes, there's no reason in the embedded world that would prevent a 

See above.  You're not going to get rid of DES.  And, as I've pointed out
earlier, the embedded world won't even know your diediedie exists, and if
it's pointed out to them they'll ignore it.  Alarms, for example, send data
quantities measured in bytes, so some academic attack that would take 500 
million years to acquire the necessary data isn't going to lose anyone any 
sleep.  It's a nice piece of work, but you need to look at what practical 
effect it has on real, deployed systems...

Peter.

---

From: Derek Atkins <[email-masked]>
Date: Thu, 08 Sep 2016 11:01:24 -0400

Tony Arcieri <[email-masked]> writes:

> EMV chip cards support RSA digital signatures. Granted earlier EMV cards used
> ridiculously small key lengths (i.e. 320-bits), but they have been gradually
> ratcheted up to e.g. 768 or 1024-bits.

So they are finally up to 80-bit security?  Woohoo!
That makes me feel so safe.

> These cards number in the billions (10s of billions?) and the chips are priced
> in the penny range.
>
> I don't think it's impractical to ship hardware accelerated asymmetric crypto
> primitives on chips that meet the specifications you're describing. The
> payments industry has definitely shown it's possible.

Payments are a very poor example..  Several seconds per transaction?
That's not usable performance.  Look at all the pushback from consumers
that have been happening since the changeover to chip cards in the US
this past year.

-derek

---

From: Derek Atkins <[email-masked]>
Date: Thu, 08 Sep 2016 11:21:00 -0400

> effect it has on real, deployed systems...

EXACTLY!

-derek

---

From: Kyle Rose <[email-masked]>
Date: Thu, 8 Sep 2016 12:08:13 -0400

On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann <[email-masked]>
wrote:

> complaints about it vanishing.

...

>  Alarms, for example, send data

To this class of examples, the problem seems to be less the implications
for security of the specific systems making use of weak crypto, and more
the effect the survival of weak options for crypto might have on other
systems. We don't want more general systems to be subject to attacks that
may not be applicable to the resource-constrained target systems, but that
requires us to answer a few questions about those constrained systems:

(1) Is the target system isolated, such that a compromise cannot either
leverage transitive trust to another system or provide an attacker a beach
head from which to attack (surreptitiously probe, etc.) other systems?

(2) Is the weak crypto being used by the target system in a way that
renders both the known and expected attacks inapplicable?

If we can answer #1 "yes", then all a user is dealing with is a device that
might malfunction in a well-defined/delineable way upon compromise, with no
impact on other systems. It might be hard to definitively answer because,
for instance, a light bulb malfunctioning might create a safety incident if
the light bulb is a control panel indicator for some problem, so I don't
want to minimize the difficulty of coming to a "yes" answer here.

If the answer to #1 is "no" or is too difficult to answer, however, then we
have to actually analyze the weaknesses in the crypto with respect to how
the device could be used.

Where I'm going with this is that #1 is going to be particularly difficult
to answer if the protocol making use of the weak crypto is TLS and the
device is connected to the internet, simply because the potential for
complex interactions is so high. The safest course may be to continue to
deprecate weak crypto for TLS, IPsec, etc. under the assumption that the
systems making use of those protocols are both powerful enough and
well-connected enough to cause a problem if compromised. Nothing stops
resource-constrained systems from continuing to use old implementations of
TLS that do support weak crypto, though I question the wisdom of producing
parts with no upgrade path that speak such a complex, general transport
protocol rather than something naturally 0-RTT in the steady state that
would use less CPU and power, have a smaller TCB, and not rely on an ASN.1
implementation for domain isolation (e.g., Kerberos).

Which leads directly into the issue of the potential for implementation
vulnerabilities, something that is probably even more likely to lead to
loss of control than weak crypto, and which may ultimately force users to
demand IoT devices for which the answer to #1 is always "yes". So I wonder
if all the worrying about weak crypto is just a red herring compared with
the exploits we are actually going to encounter.

Kyle

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 8 Sep 2016 09:28:26 -0700

> That makes me feel so safe.

1024-bit RSA is certainly less than ideal, but certainly better than
nothing, which was the claim about devices in this class.

Comparisons with symmetric cryptography aren't exactly fungible like that
either: though I personally consider 1024-bit RSA keys to be weak, to my
knowledge one has not been factored successfully by the general public.

> that have been happening since the changeover to chip cards in the US

The cryptography is not the bottleneck in this case: poor implementations
of the protocol are. Use the same card for an NFC transaction (provided
it's capable) and the delay will be considerably less.

Also, an asymmetric primitive is something you'd use to exchange keys and
sign transcripts for session initialization, after which all subsequent
communication is symmetric. Does a second of handshaking actually matter if
all subsequent communication is hardware accelerated symmetric
cryptography? (I'm sure it might for some, but won't for many others)

The real point is that if verticals within the "IoT space" were to
standardize on a particular set of asymmetric primitives and ship them en
masse like the payments industry did, economies of scale can drive the
costs down to the levels they deem acceptable. But they seem unwilling to
do the up-front development work and want to continue using the MCUs
they're already using, many of which have no crypto accelerators
whatsoever...

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Sep 2016 19:46:00 +0300

> On 8 Sep 2016, at 7:08 PM, Kyle Rose <[email-masked]> wrote:
> 
> On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann <[email-masked] <mailto:[email-masked]>> wrote:
> To this class of examples, the problem seems to be less the implications for security of the specific systems making use of weak crypto, and more the effect the survival of weak options for crypto might have on other systems. We don't want more general systems to be subject to attacks that may not be applicable to the resource-constrained target systems, but that requires us to answer a few questions about those constrained systems:
> 
> (1) Is the target system isolated, such that a compromise cannot either leverage transitive trust to another system or provide an attacker a beach head from which to attack (surreptitiously probe, etc.) other systems?
> 
> (2) Is the weak crypto being used by the target system in a way that renders both the known and expected attacks inapplicable?

Good questions, no doubt. But I don’t think they can be answered.

Someone is going to specify protocols and algorithms. This could be the IETF. This could be the ITU, or IEEE, or some other SDO. Makes no difference.
Someone is going to implement these protocols and algorithms in some combination of hardware and software.
Someone is going to combine this implementation with other parts like network stack, wired or wireless communications, memory to create a “brains” for IoT devices.
Someone is going to build a sensor or an actuator that includes that “brains” plus hardware and software. This could be a lightbulb, and smoke detector, a temperature sensor.
Someone is going to use this sensor or actuator as part of a system: a car, a refrigerator, an HVAC system, a door alarm.
Someone is going to deploy these systems in a home, in a data center, in a plane, in a nuclear power plant. 

It’s that last step that determines how attractive this is going to be to attackers and what value is going to be protected by a device using these protocols and algorithms. And the last two steps determine how isolated the “thing” will be. We as an SDO are 7 steps removed from this, so we can’t make that determination. We can be sure that if we specify a protocol that will prove successful (as in adopted) by industry, that protocol will protect lightbulbs, but it will also end up protecting critical infrastructure, high-value targets and probably even lives.

We can’t even make Peter’s assumption that these things send only a few bytes of data, because many things send very little data. But some things will send a lot of data. And putting “no more than 1 MB per day” in the security considerations section is an exercise in futility.

Yoav

---

From: Kyle Rose <[email-masked]>
Date: Thu, 8 Sep 2016 13:36:57 -0400

On Thu, Sep 8, 2016 at 12:46 PM, Yoav Nir <[email-masked]> wrote:

> Someone is going to specify protocols and algorithms. This could be the
> IETF. This could be the ITU, or IEEE, or some other SDO. Makes no
> difference.
> Someone is going to combine this implementation with other parts like
> network stack, wired or wireless communications, memory to create a
> “brains” for IoT devices.
> Someone is going to build a sensor or an actuator that includes that
> “brains” plus hardware and software. This could be a lightbulb, and smoke
> detector, a temperature sensor.
> Someone is going to use this sensor or actuator as part of a system: a
> car, a refrigerator, an HVAC system, a door alarm.
> It’s that last step that determines how attractive this is going to be to
> attackers and what value is going to be protected by a device using these
> protocols and algorithms. And the last two steps determine how isolated the
> “thing” will be.
>

Not necessarily. Manufacturers may be able to push some of those isolation
properties higher into the list. E.g., if the silicon simply cannot speak a
more general protocol even if compromised, or has some other physical
constraint (e.g., data rate, CPU power, etc.) that limits its
expressiveness, you may be able to make provable statements about the
potential impact of compromise. We obviously can't impose those
restrictions on manufacturers, but I don't know if it's completely hopeless
to create standards or compile best practices for mitigating compromise of
insecure devices.

But this brings me back to my earlier post where I said this sounds like a
research problem: the IETF is not anywhere near being in the position of
making such recommendations. And I'm not convinced that this path is a
productive use of our time, when hardware being hardware means that
increased functionality (better crypto, upgradability) gets cheaper all the
time.

OTOH, manufacturers being manufacturers means that security and
upgradability are baked in only when users demand it, and users being users
means that no one demands either until it's too late. So it's possible
there's real value in doing the research and then creating safety standards
for classes of devices that seem to be designed to atrophy, but it's
probably more useful for that standardization to focus on network isolation
rather than on crypto since the crypto is only one small part of the TCB.

Is the era in which the marginal cost of upgradability is too expensive to
support a short one, or is this a problem we're going to be dealing with
for a long time? If the latter, then I'm starting to see some value in not
having everything be globally-routable or even talk IP.

Kyle