jitterentropy_rng on armv5 embedded target

jitterentropy_rng on armv5 embedded target

[Alexander Dahl]

Hello,

after upgrading OpenSSL to 1.1.1g on an armv5 based embedded target I had a 
deeper look into entropy generation for that device and stumbled over the in 
kernel 'jitterentropy_rng' module.

As far as I understood it's supposed to do the same as the well known 
'haveged' or the userspace daemon 'jitterentropy-rngd' by Stephan Müller [1], 
right? (Although those daemons would solve my problem, I currently try to 
avoid them, because memory on my platform is very restricted and every 
additional running userspace process costs at least around 1 MB.)

If so, then how is it supposed to be set up? I built it for 4.9.x LTS, but 
after loading it with 'modprobe' I see nothing in the kernel log and there's 
no significant change in /proc/sys/kernel/random/entropy_avail (stays well 
below 100 most of the time). Isn't that module supposed to gather entropy from 
cpu timing jitter?

Puzzled
Alex

[1] https://www.chronox.de/jent.html

Re: jitterentropy_rng on armv5 embedded target

[Stephan Mueller]

Am Freitag, 8. Mai 2020, 13:40:08 CEST schrieb Alexander Dahl:

Hi Alexander,

> Hello,
> 
> after upgrading OpenSSL to 1.1.1g on an armv5 based embedded target I had a
> deeper look into entropy generation for that device and stumbled over the in
> kernel 'jitterentropy_rng' module.
> 
> As far as I understood it's supposed to do the same as the well known
> 'haveged' or the userspace daemon 'jitterentropy-rngd' by Stephan Müller
> [1], right?

Yes, precisely. In fact, it is the identical code base of the core 
functionality that both the kernel and the jitterentropy-rngd uses. See the 
comment at the top of the kernel source code.

> (Although those daemons would solve my problem, I currently try
> to avoid them, because memory on my platform is very restricted and every
> additional running userspace process costs at least around 1 MB.)

If you compile it and you also have AF_ALG for RNGs compiled, you can use it 
through the AF_ALG interface (see [1] for a library). But IMHO if you are 
space-constrained, you do not want that code.

Rather use the jitterentropy-library from [2] and link it straight from your 
application.
> 
> If so, then how is it supposed to be set up? 

It is intended for in-kernel purposes (namely to seed its DRBG).

> I built it for 4.9.x LTS, but
> after loading it with 'modprobe' I see nothing in the kernel log and there's
> no significant change in /proc/sys/kernel/random/entropy_avail (stays well
> below 100 most of the time). Isn't that module supposed to gather entropy
> from cpu timing jitter?
> 
> Puzzled
> Alex
> 
> [1] https://www.chronox.de/jent.html

[1] https://www.chronox.de/libkcapi.html

[2] https://github.com/smuellerDD/jitterentropy-library


Ciao
Stephan

Re: jitterentropy_rng on armv5 embedded target

[Alexander Dahl]

Hello, Stephan,

Am Freitag, 8. Mai 2020, 13:58:14 CEST schrieb Stephan Mueller:
> > (Although those daemons would solve my problem, I currently try
> > to avoid them, because memory on my platform is very restricted and every
> > additional running userspace process costs at least around 1 MB.)
> 
> If you compile it and you also have AF_ALG for RNGs compiled, you can use it
> through the AF_ALG interface (see [1] for a library). But IMHO if you are
> space-constrained, you do not want that code.
> 
> Rather use the jitterentropy-library from [2] and link it straight from your
> application.

That would be dropbear or openssl (and applications using libssl). While that 
would certainly be nice, I fear it's out of my scope. ;-)

> > If so, then how is it supposed to be set up?
> 
> It is intended for in-kernel purposes (namely to seed its DRBG).

Okay and DRBG has nothing to do with /dev/random ? Then where do the random 
numbers for that come from (in the current or previous kernels without your 
new lrng)?

Curious
Alex

Re: jitterentropy_rng on armv5 embedded target

[Stephan Mueller]

Am Freitag, 8. Mai 2020, 14:17:25 CEST schrieb Alexander Dahl:

Hi Alexander,

> > > If so, then how is it supposed to be set up?
> > 
> > It is intended for in-kernel purposes (namely to seed its DRBG).
> 
> Okay and DRBG has nothing to do with /dev/random ?

Nope, it is used as part of the kernel crypto API and its use cases.

> Then where do the random
> numbers for that come from (in the current or previous kernels without your
> new lrng)?

The DRBG is seeded from get_random_bytes and the Jitter RNG.


Ciao
Stephan

Re: jitterentropy_rng on armv5 embedded target

[Alexander Dahl]

Hello,

Am Freitag, 8. Mai 2020, 14:22:02 CEST schrieb Stephan Mueller:
> Am Freitag, 8. Mai 2020, 14:17:25 CEST schrieb Alexander Dahl:
> > Okay and DRBG has nothing to do with /dev/random ?
> 
> Nope, it is used as part of the kernel crypto API and its use cases.
> 
> > Then where do the random
> > numbers for that come from (in the current or previous kernels without
> > your
> > new lrng)?
> 
> The DRBG is seeded from get_random_bytes and the Jitter RNG.

Oh, I was not precise enough. I wanted to know where /dev/random gets its 
numbers from. As far as I understood now: not from DRBG? (Which is sufficient 
knowledge for my current problem.)

Greets
Alex

Re: jitterentropy_rng on armv5 embedded target

[Stephan Mueller]

Am Freitag, 8. Mai 2020, 14:26:41 CEST schrieb Alexander Dahl:

Hi Alexander,

> Hello,
> 
> Am Freitag, 8. Mai 2020, 14:22:02 CEST schrieb Stephan Mueller:
> > Am Freitag, 8. Mai 2020, 14:17:25 CEST schrieb Alexander Dahl:
> > > Okay and DRBG has nothing to do with /dev/random ?
> > 
> > Nope, it is used as part of the kernel crypto API and its use cases.
> > 
> > > Then where do the random
> > > numbers for that come from (in the current or previous kernels without
> > > your
> > > new lrng)?
> > 
> > The DRBG is seeded from get_random_bytes and the Jitter RNG.
> 
> Oh, I was not precise enough. I wanted to know where /dev/random gets its
> numbers from. As far as I understood now: not from DRBG? (Which is
> sufficient knowledge for my current problem.)

Interrupts, HID events, block device events, external sources.

For a full analysis, see [1]

[1] https://bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/
LinuxRNG/LinuxRNG_EN.pdf


Ciao
Stephan