Read uninitialized SRAM values

[undacmic]

Hello and thanks in advance for reading my post.

I am currently working on my dissertation, trying to implement a digital signing algorithm on a Arm Cortex-M0+ microprocessor. I'm using a NUCLEO-G0B1RE board with a stm32 with the same series. This board does not come with a TRNG peripheral and I don't want to use a packaged one, as I'm trying to understand the process of crceating an RNG as well.

From some posts I have read (either on this forum or other ones), it seems that uninitialized SRAM is a good starting point for my entropy source. I'm also taking into consideration using time jitter between two oscillators (mainly the 32 kHz +- 5% RC oscillator and the PLL block).

I use VSCode and I wrote my own linker script and startup code.

I have created a noinit section that loads into SRAM:

    .noinit (NOLOAD) : {
        *(.noinit)
    } >SRAM

SRAM is a memory zone which has the origin and length based on the memory organization chapter in the reference manual and is according to my device specifications:

    SRAM  (xrw)     : ORIGIN = 0x20000000, LENGTH = 144K

I have also created a volatile array of unsigned integers to be loaded in the noinit section:

volatile uint8_t au8Arr[1024] __attribute__((section(".noinit")));

When using Cortex-Debugger to check the values inside au8Arr in the Reset_Handler, there seems to be very little if any modification at all in bytes.

It seems that SRAM is retained even on longer power cycles (1min - 10min).

My question is how can I make the retention period much smaller (if none at all) or how can I adapt to these behaviour?

[Andrew Neil]

---

@undacmic wrote:

From some posts I have read (either on this forum or other ones), it seems that uninitialized SRAM is a good starting point for my entropy source

---

I don't think so - perhaps you are misinterpreting those posts?

While there are some proposals that do use uninitialised memory, I think they look at the analogue values within the memory array?

What you read via software is quantised into just '1' or 'zero' - so you lose the vast majority of the entropy.

The digital values that code reads from uninitialised memory do tend to be pretty constant.

[undacmic]

Honestly, it is my first time doing an embedded project and I might be misguided, but here is a list of what I've found, again I am not saying this is a correct implementation, is just that some other people seem to have tried, and using NIST statistical tests to prove the usability of the entropy source seemed good for me:

• Medium Post about creating RNG using hashed SRAM bits 
• MDPI article abour SRAM-based TRNG 

Ok, now let's say this is an incorrect assumption, what approach I should take for using only the board for entropy?

• Temperature sensor LSB? (it just seems that it is susceptible to external alterations of temperature that might result in pretty stable ADC reads)
• Time jitter?
• What can I do to read the analogue values within the memory array?
• Any other way?

[Andrew Neil · Accepted solution]

As it says in your 1st link, the randomness is "biased" by process variations - I don't think it's safe to assume that "bias" won't completely swamp other random effects?

---

@undacmic wrote:

• Temperature sensor LSB? (it just seems that it is susceptible to external alterations of temperature that might result in pretty stable ADC reads)

---

That's why you consider only the LSB - that's always going to be the least stable.

---

@undacmic wrote:

• Time jitter?

---

Yes, that's a common one

---

@undacmic wrote:

• What can I do to read the analogue values within the memory array?

---

Nothing - that's hidden by the hardware.

---

@undacmic wrote:

• Any other way?

---

Yes, many - what's practical/useful depends on the specific application.

If there were just one, simple, universal way - then chipmakers would have to go to lengths to provide TRNGs!

[undacmic]

---

Yes, many - what's practical/useful depends on the specific application.

If there were just one, simple, universal way - then chipmakers would have to go to lengths to provide TRNGs!

---

I think it's out of topic to mention, but just for context, I'm looking into a SPHINCS+ implementation, which needs some secret keys created using a PRF. I was thinking to use a hash algorithm for this, but I wanted to hash an "as random as possible" value.

---

---

@undacmic wrote:

• Time jitter?

---

Yes, that's a common one

---

Ok, I will try two approaches and benchmark my results.

One using multiple floating ADC pins on which I will try to apply some bit-wise operation.

The other using time jitter, but regarding this I have one more question.

To obtain good results (which I think should mean as much jitter as possible) which on-board clock blocks/oscillators I should use, and bigger frequency is equal to higher jitter?