Testing the PRNG driver of the Allwinner Security System A20

Testing the PRNG driver of the Allwinner Security System A20

[Corentin LABBE]

Hello

I am writing the PRNG driver for the Allwinner Security System SoC A20.

I didn't know how to test it, so I have found that char/hw_random/exynos-rng.c exposes a PRNG via the hwrng interfaces.
So I have written a HWRNG driver that use the SS PRNG via the crypto API (crypto_alloc_rng/crypto_rng_reset/crypto_rng_get_bytes)
I have attached the code in case of...

The problem is that rngtest show some failures.
cat /dev/hwrng | rngtest
rngtest: bits received from input: 1876960032
rngtest: FIPS 140-2 successes: 93771
rngtest: FIPS 140-2 failures: 77
rngtest: FIPS 140-2(2001-10-10) Monobit: 15
rngtest: FIPS 140-2(2001-10-10) Poker: 11
rngtest: FIPS 140-2(2001-10-10) Runs: 30
rngtest: FIPS 140-2(2001-10-10) Long run: 22
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=979.894; avg=109756.722; max=4882812.500)Kibits/s
rngtest: FIPS tests speed: (min=1.309; avg=32.191; max=39.986)Mibits/s
rngtest: Program run time: 72523286 microseconds

So I have questions:
- Does the use of a HWRNG driver for exposing the PRNG is a good idea ?
- Could I think the PRNG is good enough with the result of rngtest ?

Bests regards



/*
 * ss-rng.c - Random Number Generator driver for the Security System
 */

#include <linux/hw_random.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <crypto/rng.h>

struct ss_rng_ctx {
	struct hwrng rng;
	struct crypto_rng *cr;
};

static struct ss_rng_ctx ss_rng;

#define SS_SEED_LEN (192/8)

static int ss_rng_init(struct hwrng *rng)
{
	int i;
	u8 seed[SS_SEED_LEN];
	u32 *s = (u32 *)seed;
	for (i = 0 ; i < SS_SEED_LEN/4 ; i++)
		s[i] = jiffies;
	crypto_rng_reset(ss_rng.cr, seed, SS_SEED_LEN);
	return 0;
}

static int ss_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
{
	return crypto_rng_get_bytes(ss_rng.cr, buf, max);
}

static int ss_rng_probe(void)
{
	int err;
	struct crypto_rng *rng;
	const char *name;

	rng = crypto_alloc_rng("stdrng", 0, 0);
	err = PTR_ERR(rng);
	if (IS_ERR(rng))
		return err;

	name = crypto_tfm_alg_driver_name(crypto_rng_tfm(rng));
	if (strcmp(name, "rng-sunxi-ss") != 0) {
		pr_err("ERROR: Cannot get Security System PRNG, but got %s instead\n", name);
		crypto_free_rng(rng);
		return -ENODEV;
	}

	ss_rng.cr = rng;
	ss_rng.rng.name = "Security System HWRNG";
	ss_rng.rng.init = ss_rng_init;
	ss_rng.rng.read = ss_rng_read;
	err = hwrng_register(&ss_rng.rng);
	if (err != 0) {
		crypto_free_rng(ss_rng.cr);
	}
	return err;
}

static void ss_rng_remove(void)
{
	hwrng_unregister(&ss_rng.rng);
	crypto_free_rng(ss_rng.cr);
}

module_init(ss_rng_probe);
module_exit(ss_rng_remove);

MODULE_DESCRIPTION("Allwinner Security System H/W Random Number Generator driver");
MODULE_AUTHOR("Corentin LABBE <clabbe.montjoie@gmail.com>");
MODULE_LICENSE("GPL");

Re: Testing the PRNG driver of the Allwinner Security System A20

[Sandy Harris]

On Tue, Jul 1, 2014 at 7:14 AM, Corentin LABBE
<clabbe.montjoie@gmail.com> wrote:

> I am writing the PRNG driver for the Allwinner Security System SoC A20.

The datasheet my search turned up (v1, Feb. 2013) just says:  "160-bit
hardware PRNG with 192-bit seed" and gives no other details. Do you
have more info, perhaps from a more recent version or talking to the
company?

> I didn't know how to test it, so ...

Unless you have much more info, I see no point in enabling it or
writing a driver. You need a true hardware RNG to seed it, so you need
random(4) /dev/random anyway and can just use /dev/urandom for PRNG
requirements.

Using this device might have an advantage if it is much faster or less
resource-hungry than urandom, but I see nothing in its documentation
that indicates it is. Anyway, do your applications need that? And, if
so, would an application-specific PRNG be better yet?

Then there is the crucial question of trusting the device. Kerckhoff's Principle
(http://en.citizendium.org/wiki/Kerckhoffs%27_Principle)
has been a maxim for cryptographers since the 19th century; no-one
should even consider trusting it until full design details are made
public and reviewed.

Even then, there might be serious doubts, since hardware can be very
subtly sabotaged and an RNG is a tempting target for an intelligence
agency.
(http://arstechnica.com/security/2013/09/researchers-can-slip-an-undetectable-trojan-into-intels-ivy-bridge-cpus/)
That article discusses Intel and the NSA, but similar worries apply
elsewhere. Allwinner is a fabless company, so you also need to worry
about whatever fab they use.

Re: Testing the PRNG driver of the Allwinner Security System A20

[Corentin LABBE]

On 07/03/14 01:06, Sandy Harris wrote:
> On Tue, Jul 1, 2014 at 7:14 AM, Corentin LABBE
> <clabbe.montjoie@gmail.com> wrote:
> 
>> I am writing the PRNG driver for the Allwinner Security System SoC A20.
> 
> The datasheet my search turned up (v1, Feb. 2013) just says:  "160-bit
> hardware PRNG with 192-bit seed" and gives no other details. Do you
> have more info, perhaps from a more recent version or talking to the
> company?

The datasheet I used give some register info, just enough for having some "random" number out of the device.

> 
>> I didn't know how to test it, so ...
> 
> Unless you have much more info, I see no point in enabling it or
> writing a driver. You need a true hardware RNG to seed it, so you need
> random(4) /dev/random anyway and can just use /dev/urandom for PRNG
> requirements.
> 
> Using this device might have an advantage if it is much faster or less
> resource-hungry than urandom, but I see nothing in its documentation
> that indicates it is. Anyway, do your applications need that? And, if
> so, would an application-specific PRNG be better yet?
> 
> Then there is the crucial question of trusting the device. Kerckhoff's Principle
> (http://en.citizendium.org/wiki/Kerckhoffs%27_Principle)
> has been a maxim for cryptographers since the 19th century; no-one
> should even consider trusting it until full design details are made
> public and reviewed.
> 
> Even then, there might be serious doubts, since hardware can be very
> subtly sabotaged and an RNG is a tempting target for an intelligence
> agency.
> (http://arstechnica.com/security/2013/09/researchers-can-slip-an-undetectable-trojan-into-intels-ivy-bridge-cpus/)
> That article discusses Intel and the NSA, but similar worries apply
> elsewhere. Allwinner is a fabless company, so you also need to worry
> about whatever fab they use.
> 

The question of trusting is the reason that my preliminary driver made the PRNG optionnal and I think the next version will be without it.
But for people who do not care (or do not have a real RNG requirement), the output speed is better than /dev/urandom
Here is a comparison of the output speed of rng-test:
with /dev/urandom
rngtest: input channel speed: (min=623.523; avg=17402.670; max=3906250.000)Kibits/s
with /dev/hwrng and ss-rng/sunxi-ss loaded
rngtest: input channel speed: (min=1.193; avg=113.604; max=4768.372)Mibits/s
So an average speed gain of x5

Apart from trusting, does the results of rng-test are good enough ?

Thanks for your answer

Regards