I'm looking at WICED 3.5.2 has what looks like a crypto PRNG. In the file named "wiced_crypto.c", the default PRNG implementation is initialised like this:
static wiced_crypto_prng_t prng_well512 =
.get_random = &prng_well512_get_random,
.add_entropy = &prng_well512_add_entropy
It's using WELL512 algorithm which is not cryptographically secure. It even has this comment:
static uint32_t prng_well512_get_random( void )
* Implementation of WELL (Well equidistributed long-period linear) pseudorandom number generator.
* Use WELL512 source code placed by inventor to public domain.
* This is NOT cryptographically secure pseudorandom number generator (CSPRNG).
* If need CSPRNG please use third party implementation, for example OpenSSL (it includes CPRNG),
* FORTUNA algorithm (implementation can be found in PostgresSQL).
* Current PRNG can be used for seeding them.
So, why in the world is this code there? Why is a PRNG that's explicitly stated to be not cryptographically secure used in a module with a name that implies cryptographic security?
In addition to that it's seeded with "host_platform_get_cycle_count()", which doesn't sound like a good source of entropy at all.
Its surprising how much of our day is devoted to these topics, in no particular order
debugging RS232 connections
While we don't have any direct control over updates, and little hope to obsolete RS232 in our lifetimes,
when it comes to RNG this is an area that is continued focus for our SDKs. Why? A weak RNG
makes weak key material and compromises the security model.
To be honest I don't know when well512 was added but we had nothing to do with it.
The best solution IMO is to use hardware TRNG like STM32F417 . Our SDKs have direct integration to various HW TRNGs.
Next best is a software PRNG with a pedigree. Our crypto library includes ANSI X9.31 AES128
It was pointed out that system clock is a questionable source of entropy. X9.31 uses an input
called DT (date time) which includes microsecond granularity, along with key and IV.
So you load it up, crank it through some AES rounds, and voila out pops a PRNG.
Make sure you use a good key and by all means never reuse the IV.
Feel free to contact us for info on our X9.31 SW library, then plug it with an instance of
Appreciate the answer, but it's not clear why Broadcom support are tagging you to answer it. I realise I need to provide a better PRNG myself, but I'd rather find out from them directly what their process was in including insecure code. I only inspected the code because of their history of shipping broken code, so at a least casual inspection of the crypto code sounded like a good idea. But how many people won't bother and will ship broken crypto as a result?
Appreciate the answer, but it's not clear why Broadcom support are tagging you to answer it.
Because Steve and cypherbridge have alot of expertise in this area that is specific to WICED.
His uSSL is integrated into the WICED SDK.
Additionally, Cypherbridge's SDKPac (uSSL, uFTP and uMQTT, optional uFile encrypted file system, etc.) is built around WICED and the associated development platform.
While discussing with others internally that are much more in touch with this subject, it seems that a major hurdle for IoT devices in general is that they aren't in a position to gather/accumulate much entropy before they are asked to do something that is cryptographically sound.
Ideally, it seems that the end-product/system itself should be adding entropy on a regular basis from what ever sources it has available.
While scan results are a good source of entropy for an 802.11 radio, the radio itself may not be available when the device is first started and a random number is required, hence the use of cycle counters.
Note here that the team mentioned that the wiced_crypto_set_prng() function can be leveraged by customers to implement their own (e.g. from OpenSSL as pointed out in your post) cryptographic algorithm into our framework; we should do a better job of spelling out that customers need to use their own cryptographically secure PRNG, especially since the file/function names are somewhat misleading.
Ultimately, this has been escalated internally, and the tradeoffs associated with providing our own cryptographically secure PRNG are being -. As such, we are looking at sources of entropy that are available within our SoC environment as we could not expect one of our partners to implement this functionality in their libraries.
IMO, this is what can be done, which is a good tradeoff between security and convenience:
I think build-time warning offers the best tradeoff.
I'd like to stress once again that the main thing is at least making the user of the SDK aware of the default choice. If I did not manually inspect the code on a whim, it would not have occurred to me that I have to implement my own CSPRNG.