Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 2 answers
  • Subscribers 16 subscribers
  • Views 341 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2340R5: RNG Quality and SDK Testing Methods for CC2340R22

QIngtian Yang
Prodigy 60 points
Part Number: CC2340R5
Other Parts Discussed in Thread: SYSCONFIG, , CC2642R

Tool/software:

We initially tested the CC2340R22（use sdk 8.10） for random number generation using the function int_fast16_t RNG_getRandomBits(RNG_Handle handle, void *randomBits, size_t randomBitsLength) to retrieve random numbers, and found the quality to be lower than expected. After conducting the test four times with resets in between, we collected four sets of data, which showed deviations ranging from 20-30%.

Subsequently, we revised the relevant configuration files by replacing the current lrf_rfe_binary_ble5_cc23x0r5.c and rcl_settings_adc_noise.c files with those from the version 7.40 SDK. The results we obtained afterward indicated a marked improvement, yet there remains a considerable discrepancy.

This leads us to inquire about the following points:

  1. Does our test outcome suggest that the RNG component in the latest SDK(8.10) and chip versions is not as efficient as desired?
  2. What methods do you employ to verify the functionality of the RNG, and could we possibly refer to these methods for our own testing procedures?"
  • 0
    TI__Guru* 99610 points

    Hi, 

    Thank you for reaching out. 

    As your results suggest, the RNG driver was updated in SDK 7.40 to improve the quality of the results obtained. You can reference the release notes of the CoreSDK of the same SDK version for more details: https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/7.40.00.64/exports/docs/simplelink_mcu_sdk/release_notes_coresdk_lpf3_7_40_02_00.html 

    Focusing on the results you obtained with SDK 7.40 - The first element, I would like to point out, is that the data set considered remains fairly small, leading a small variation on the number of duplicates impacting a lot the deviation percentage. The second element I see is that, for the largest data set you actually have a pretty low deviation. 

    I am checking with my colleagues which details of our testing process can be shared online. To help sharing the right elements, would you like mentioning which other elements - despite the number of duplicates - you are checking in your tests?

    Best regards, 

  • 0 in reply to Clément
    Prodigy 60 points

    I apologize for any confusion in my previous response. I've added some information to clarify: we are currently using SDK version 8.10, and its random number performance is not as good as the earlier 7.40 version. As shown above, there is still a deviation of more than 10% with a data volume of 800,000. In our current testing, we've simply added a while loop to generate hundreds of thousands of random numbers and print them out for comparison using formulas.

  • 0 in reply to QIngtian Yang
    TI__Guru* 99610 points

    Hi, 

    Thank you for adding these details. 

    Can you confirm my understanding of your request?

    • On SDK 7.40, RNG behavior is ok
    • On SDK 8.10, RNG behavior is incorrect

    Appreciate your help,

    Best regards, 

  • 0 in reply to Clément
    TI__Guru* 99610 points

    Hi, 

    I have two additional elements I would like to add to my previous answers: 

    1. In case it was not mentioned before, on CC2340Rx device only a RNG (Random Number Generator) is available - i.e. there is no TRNG (True Random Number Generator) on the CC2340Rx. In order to collect entropy, the RF ADC can be used. This is documented here: https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/8.10.01.02/exports/docs/drivers/doxygen/html/_r_n_g_8h.html 
    2. SysConfig can be used for further configure the RNG driver

    I hope this will help,

    Best regards, 

  • 0 in reply to Clément
    Prodigy 60 points

    Hi there,

    Thank you for the additional information provided in your previous message.

    1. We are indeed utilizing the ADC as a source of entropy, which is also referenced in the noise-related file rcl_settings_adc_noise.c that you mentioned.
    2. I have also reviewed the code generated by SysConfig and noticed that it aligns with our current code logic. However, I was wondering if there are any alternative approaches or solutions that we might consider.

    Furthermore, I would be interested to learn about your internal testing and release procedures for the random number generation features in the SDK version 8.10. Ensuring that the RNG functions are reliable and secure is critical for our application, and understanding the testing protocols can provide us with additional confidence.

    Looking forward to your insights.

    Best regards,

  • 0 in reply to QIngtian Yang
    TI__Guru* 99610 points

    Hi, 

    Detailed testing procedure cannot be shared on public forums. They are only provided under NDA as far as I am aware. 

    Thank you for your comprehension.

    Best regards, 

  • 0 in reply to Clément
    Prodigy 60 points

    When using the same hardware and application code, the random numbers generated by the 8.10 SDK are not ideal. We have tried adjusting the size of RNGLPF3RF_noiseInputWordLen. What other possible solutions are there to improve the quality of the random numbers?

  • 0 in reply to QIngtian Yang
    TI__Guru* 99610 points

    Hi, 

    The amount of noise collected should be large enough to ensure the entropy obtained is good enough. Based on the elements I have it seems the entropy level is ~ 1 bit entropy/ 1 bit noise. 

    In addition to the previous, one can run "health checks" on the entropy - for example the tests defined by NIST SP 800-90B. We are working on implementing these tests in the RNG driver. The updated driver will be release in a future SDK version. 

    I hope this will help,

    Best regards, 

  • 0 in reply to Clément
    Prodigy 60 points

    Thank you for your insights and suggestions.

    We have been utilizing TI's API to collect noise, and from my understanding, the noise should primarily influence the randomness of the initial seed rather than the quality of the random numbers generated subsequently. However, I acknowledge that there might be more nuances to this process that we are not currently accounting for.

    To enhance the reliability of our current product, I would greatly appreciate if you could provide more detailed and actionable guidance. Specifically, we are looking for recommendations on best practices for noise collection, seed generation, and any other relevant aspects that could contribute to the overall quality and unpredictability of the random numbers produced by our system.

    Looking forward to your expert advice.

    Best regards

  • 0 in reply to QIngtian Yang
    TI__Guru* 99610 points

    Hi, 

    Please note the CC2340R5 device does NOT offer a True Random Number Generator (TRNG). If the success of the product you are building depends on such TRNG, you should consider selecting other chipsets, such as the CC2642R or CC2640R2. 

    Best regards, 

  • 0 in reply to Clément
    Prodigy 60 points

    Dear TI Engineer,

    Thank you for your prompt response. We are aware that the CC2340R5 device does not have a True Random Number Generator (TRNG) as you've mentioned. As stated in the manual, "The CC2340R device supports Random Number Generation (RNG) using on-chip analog noise as the non-deterministic noise source for the purpose of generating a seed for a cryptographically secure counter deterministic random bit generator (CTR-DRBG) that in turn is used to generate random numbers for keys, initialization vectors (IVs), and other random number requirements."

    While we understand the internal logic and the RNG capabilities of the CC2340R5, we have encountered an issue that is not explained by the absence of a TRNG. Under the same testing conditions, the random number quality from the same chip was good when using the older version of the SDK. However, there is a noticeable degradation in quality when using the 8.10 SDK version. This discrepancy cannot be solely attributed to the lack of a TRNG on the chip.

    We would appreciate if you could provide further insights or considerations regarding this issue. Are there any known changes in the RNG implementation between the SDK versions that could account for this difference? Or might there be other factors at play that we should be aware of?

    Looking forward to your expert guidance on this matter.

    Best regards,

  • 0 in reply to QIngtian Yang
    TI__Guru* 99610 points

    Hi,

    I am awaiting some feedback from the experts of this component.
    To speed up the process, I would like to kindly request you to provide more details on the tests you are running. If possible, provide some code snippets so we can review those. 

    Appreciate your patience,

    Best regards, 

  • 0 in reply to Clément
    Prodigy 60 points

    Thank you for your message. I appreciate your efforts in gathering feedback. To provide more context, my testing method involves initializing the random seed using RCL_AdcNoise_get_samples_blocking and RNGLPF3RF_conditionNoiseToGenerateSeed. Then, I initialize RNG with RNG_init and continuously call Random_generateRandomBytes in a while (1) loop until I generate enough bytes. I will prepare the relevant code snippets and send them over shortly.

    Thanks for your patience!

    Best regards,

  • 0 in reply to QIngtian Yang
    TI__Guru* 99610 points

    Hi, 

    Thanks!

    One more element I would like to highlight here - The entropy used by the RNG originates from ambient noise. In theory this noise can be considered as white. In practice this noise is produced by physical sources that are not purely white. For this reason, if you take many samples from the RNG, you may see some elements to reproduce. 
    The intended way of using the RNG is to seed a software pseudo-random number generator - and then use the numbers generated by the software pseudo-random number generator. 
    The use I am describing is actually better practice as it reduces power consumption and provides faster responses. 

    Best regards, 

  • 0 in reply to Clément
    Prodigy 60 points

    Thank you for your insights. However, based on our testing under consistent external conditions, the issue should not be attributed to poor quality of the RF noise. Please encourage your technical team to verify the situation again.

    I believe that my code only uses RF noise as the random seed, and the subsequent random numbers are generated by the software. Therefore, the quality of the RF noise should not affect the quality of the subsequent random numbers. If my understanding is incorrect, please feel free to correct me.