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

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

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

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

]]>