SWRA667 January   2020 CC1312PSIP , CC1312R , CC1314R10 , CC1352P , CC1352P7 , CC1352R , CC2642R , CC2642R-Q1 , CC2652P , CC2652R , CC2652R7 , CC2652RB , CC2652RSIP

 

  1.   Cryptographic Performance and Energy Efficiency on SimpleLink™ CC13x2/CC26x2 Wireless MCUs
    1.     Trademarks
    2. 1 Abbreviations and Acronyms
    3. 2 Introduction
    4. 3 Benefits of Cryptographic Acceleration in Embedded Security Solutions
    5. 4 TI Drivers for SimpleLink MCUs
      1. 4.1 Power Management Overview
      2. 4.2 Return Behavior
        1. 4.2.1 Runtime Overhead
      3. 4.3 Efficient Power Management
    6. 5 CC13x2/CC26x2 Crypto Peripherals
      1. 5.1 AES and Hash Crypto Accelerator
      2. 5.2 Public Key Accelerator
        1. 5.2.1 ECDH Power Management Driver Example
      3. 5.3 TRNG
    7. 6 Benchmarks
      1. 6.1 AES and Hash Crypto Accelerator Based Drivers
        1. 6.1.1 AES CBC
        2. 6.1.2 AES CCM
        3. 6.1.3 AES GCM
        4. 6.1.4 AES CTR DRBG
        5. 6.1.5 SHA-224
        6. 6.1.6 SHA-256
        7. 6.1.7 SHA-384
        8. 6.1.8 SHA-512
      2. 6.2 PKA Engine Based Drivers
        1. 6.2.1 ECDH
        2. 6.2.2 ECDSA
        3. 6.2.3 ECJPAKE
      3. 6.3 TRNG Based Drivers
        1. 6.3.1 TRNG
    8. 7 Conclusion
    9. 8 References
    10.     Appendix: Plots of Blocking vs Polling Performance

5.3 TRNG

The true random number generator (TRNG) in the SimpleLink CC13x2/CC26x2 devices uses 24 free running oscillators (FRO) that are repeatedly sampled and collated in a linear feedback shift register (LFSR). After a sufficient number of samples have been collected and merged into the LFSR, the entropy can be read out from the registers and the TRNG begins collecting more samples. At minimum, the TRNG generates 64 bits of random output. The entropy content of these 64 bits depends on the amount of samples gathered from the FROs. The default number of samples the driver requires before reading out entropy from the TRNG is 240000. This works out to 5 ms at the highest FRO sampling rate and is enough to generate 64 bits of entropy.

The most commonly requested random number sizes will be 128 bits and 256 bits to generate symmetric or asymmetric keying material. These operations will take the TRNG driver 10 ms and 20 ms respectively. The CPU is not needed while the TRNG samples the FROs in the background. The sampling of the FROs takes up the vast majority of the overall duration. This makes blocking or callback return behavior attractive to save power or enable the CPU to perform other operations in the interim.

Newer TRNG driver implementations feature an entropy pool that contains pre-generated entropy. When the application requests a number of random bytes, the driver will first deplete its entropy pool before using the TRNG hardware for a specific request. If there was enough entropy in the pool to fulfil the request, the driver returns immediately regardless of return behavior and refills the entropy pool in the background. The choice of return behavior is consequently only relevant during periods of high TRNG driver activity when the entropy pool is depleted.

For benchmark purposes, we always assume that the entropy pool is empty when a TRNG_generateEntropy() call is made. The use of the entropy pool only allows us to move the entropy generation to earlier in time. This reduces latency and allows for increased parallelism between entropy generation and operations that consume entropy. That parallelism can reduce the amount of time the device spends in active or idle compared to standby and thus reduces power consumption.

Table 5. Drivers Using the TRNG

Driver Recommended Return Behavior
TRNG Blocking or Callback