Comments on: Smart meter crypto flaw worse than thought

By: Nate Lawson

Nate Lawson — Mon, 08 Mar 2010 04:58:47 +0000

Thanks for the nice reply. It’s good you’ve done some analysis, but more in-depth review of a cryptographic random source should be performed. Here’s one that I consider a good example review (disclaimer: I worked on some of it)

http://www.cryptography.com/resources/whitepapers/VIA_rng.pdf

By: DoubleO

DoubleO — Mon, 01 Mar 2010 20:26:57 +0000

In Z-stack 2.3, the least significant bit of the ADC register (which is very noisy) is used to construct the seed values. It is read multiple times and those bits are used to construct the initial seed of the desired length. Chapter 19.12 in the CC2530 user’s guide explains the random number generator of the CC2530, including plots of random data from 20 million samples: http://focus.ti.com/lit/ug/swru191/swru191.pdf

By: Nate Lawson

Nate Lawson — Wed, 17 Feb 2010 17:27:07 +0000

Right, and this is a general problem with other public key crypto as well. For example, (EC)DSA can be compromised if you know a small fraction of the random nonce (not key!) bits.

The moral is: randomness is very important in public key crypto and you can’t just hand-wave and say a fix is “good enough.”

By: Travis Goodspeed

Travis Goodspeed — Wed, 17 Feb 2010 05:38:24 +0000

ECQMV is vulnerable to an attack against the static private key when the top 4 bits of the ephemeral private key are known. The static key pair is exposed even though it is generated off-meter with a presumably good RNG.

By: Nate Lawson

Nate Lawson — Tue, 09 Feb 2010 22:30:35 +0000

I’m questioning two points that you seem confident in but could warrant further review:

1. That static key pairs are “unlikely to be generated” using the Z-Stack insecure PRNG

2. That the ADCTSTL register provides enough entropy, even with a secure PRNG

I’m guessing your criteria for #1 is that key generation is probably done on a general purpose computer before production, and thus is unlikely to share an implementation with Z-Stack. Is this the case? How likely is it that they reused code from Z-Stack?

Evidence points to #2 being a problem, even with a secure PRNG. Careful modeling of the entropy obtained from ADCTSTL is needed before making claims about it. Unfortunately, the latest version of Z-Stack moved this function out of the library, so it’s not easy to review exactly how it’s used (reseeding rate).

By: robert

robert — Tue, 09 Feb 2010 05:45:29 +0000

I can assure you I am very familiar with the crypto specification and typical implementations for these meters. The ECC library has fixed functions for the ZigBee Smart Energy security cluster. The library requires two user-provided callback functions:

1) A random number generator
2) AES-MMO cryptographic hash

(2) is a callback as many chips have an internal AES-128 block cipher accelerator, thus the soft (and comparatively large) AES-128 block cipher also included in the library can normally be elided. Because this has a very fixed function, it is not really open to abuse.

(1) is a callback because many chips/stacks provide their own RNG. The aim here is to make the library as small as possible due to the constrained resources of the chips this is targeted at. Therefore, if reuse can be done, it should be.

Therefore, the customer cannot “create any number of implementatins with variations on use of crypto”.

Of course, if an implementer decides to use a PRNG with low entropy for the RNG (which the ZigBee Specification says should be FIPS 140-2 compliant) then it will cause potential problems as has been discovered.