Re: [Cfrg] [TLS] 3DES diediedie

[Ilari Liusvaara <[e-mail]>]

On Wed, Sep 07, 2016 at 04:15:05AM +0000, Peter Gutmann wrote:

> 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.

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].

> 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).

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.

> 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.

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.
 
> 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.

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...
 
> 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).

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