Skip to contentSkip to conversation

Testing the PRNG driver of the Allwinner Security System A20

DISCUSSION Corentin LABBE 2 participants 3 messages Jul 1, 2014 – Jul 3, 2014 Crypto API

lore
Share & tools
lore
#0 lore raw

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 <[email protected]>"); MODULE_LICENSE("GPL");

#1 lore raw
Quoted 1 line · Corentin LABBE

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?

Quoted 1 line

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.

#2 lore raw
Quoted 9 lines · Sandy Harris
Quoted 1 line · Corentin LABBE

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.

Quoted 19 lines
Quoted 2 lines

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.

Quoted 8 lines

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