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.
1 of 1 people found this helpful
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?
1 of 1 people found this helpful
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:
- In the library API, separate the concepts of "normal" PRNG and a cryptographically secure PRNG (similar to Random vs SecureRandom in Java).
- For a CSPRNG, replace WELL512 with a good software CSPRNG implementation by default.
- As you point out, providing a good entropy source is not possible, because it's highly platform-specific, so do not provide default entropy source for CSPRNG at all, it should be fatal error to use it without explicitly initialising it with your own implementation, OR
- If you do make the default source of entropy something like the clock (so that TLS works out of the box with minimum setup), emit an unmissable warning log message when a dummy entropy source is used. This way the user is given plenty of notice and given the chance to implement their own hardware-specific entropy source. Alternatively the message can be shown at build time if CSPRNG is not overridden in the project's Makefile, OR
- Make the user set PRNG explicitly when setting up the application, so they are making a conscious decision.
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.