On-chip randomness (V4FX)

In article <45BBCF4D.5020706@zytor.com>,
 "H. Peter Anvin" <hpa@zytor.com> writes:
|> Peter Alfke wrote:
|> > I suggest an on-chip LFSR pseudo-random sequence generator, clocked by
|> > a ring-oscillator (or equivalent) clock source and timed out by a fixed
|> > delay, derived from the xtal oscillator. That's all very simple, takes
|> > only a few CLBs, when the SRL16 is used for the LFSR.
|> > Peter Alfke, Xilinx
|> 
|> I have, more often, seen the ring-oscillator(s) sampled onto a common 
|> clock before XORing together and feeding into an LFSR.  It's a little 
|> bit bigger due to the synchronizers, but has the nice effect that the 
|> bulk of the logic is all synchronous to the system clock.

XAPP 780 contains a random bit stream generator with ring-oscillators and some
"metastability" logic. 

-- 
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

Well, the "bulk of the logic" is one CLB...
Peter Alfke

On Jan 27, 2:16 pm, "H. Peter Anvin" <h...@zytor.com> wrote:
> Peter Alfke wrote:
> > I suggest an on-chip LFSR pseudo-random sequence generator, clocked by
> > a ring-oscillator (or equivalent) clock source and timed out by a fixed
> > delay, derived from the xtal oscillator. That's all very simple, takes
> > only a few CLBs, when the SRL16 is used for the LFSR.
> > Peter Alfke, XilinxI have, more often, seen the ring-oscillator(s) sampled onto a common
> clock before XORing together and feeding into an LFSR.  It's a little
> bit bigger due to the synchronizers, but has the nice effect that the
> bulk of the logic is all synchronous to the system clock.
>
>         -hpa

David R Brooks wrote:

(snip)

> I would be careful using an un-locked PLL as a source. I tried that 
> about 20 years ago, using discretes, & gave it up. It proved highly 
> non-random.

> [Part of my Master's thesis: I was using a 74S124 VCO, with a 
> sampling-type phase detector running from a sinusoidal reference. VCO 
> frequency about 4MHz, reference 132kHz.]

I remember hearing about the 74S124 about 30 years ago.  If it is the
one I remember, it is actually a dual VCO, except that it is supposed
to be impossible to use both without them phase locking.  It might be,
then, they it could also phase lock to an external source.

-- glen

"Georg Acher" <acher@in.tum.de> wrote in message 
news:epgl8q$nek$1@news.lrz-muenchen.de...
>
> XAPP 780 contains a random bit stream generator with ring-oscillators and 
> some
> "metastability" logic.
>
> -- 
Hi Georg,
Thanks for that link, it's interesting. Of course, the method described in 
this XAPP note only protects the design from cloning. It's not going to be 
impossible to reverse engineer the configuration bit stream and find the 
secret key in the FPGA. In fact, doesn't this method of attack defeat the 
random number generator thing in all application? If an attacker has 
physical access to the design, I think the Vbatt RSA key thing is the only 
'secure' way to go, otherwise your configuration bitstream is there to see.
Thanks, Syms. 

Thank you for all follow-ups.

It seems to me that ring-oscillators and meta-stability are the "best" 
sources for weak (but true) on-chip randomness.

I greatly appreciate the pointer to the XAPP780 appnote, and would 
like to add one that I found after Austins and Peters comments.  
Here's another ring-oscillator example source code:

http://www.xilinx.com/products/boards/s3estarter/files/
s3esk_frequency_counter.pdf
http://www.xilinx.com/products/boards/s3estarter/files/
s3esk_frequency_counter.zip

So thanks again for all the valuable input!

Regards,
Marc

 "Symon" <symon_brewer@hotmail.com> writes:

>Thanks for that link, it's interesting. Of course, the method described in 
>this XAPP note only protects the design from cloning. It's not going to be 

That's a start ;-)

>impossible to reverse engineer the configuration bit stream and find the 
>secret key in the FPGA. In fact, doesn't this method of attack defeat the 

Well, with some code modification you can put the secret into LUTs and/or
"random" logic. Then it's getting harder to find it. It should be also possible
to decrypt the picoblaze instructions "online", so it's not that easy to find the
BRAM that contains the code. After all, you (as the attacker) need to know where
the SHA-stuff is done to start the attack. Using XAPP780 without modifications is
not very clever...

>random number generator thing in all application? If an attacker has 
>physical access to the design, I think the Vbatt RSA key thing is the only 
>'secure' way to go, otherwise your configuration bitstream is there to see.

Spartans have no Vbatt :-(

-- 
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias