[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

On 14/01/14 22:38, Robert Millan wrote:
> On 14/01/2014 22:25, Steven Chamberlain wrote:
>> Thankfully wheezy's 9.0 and 8.3 kernels had not enabled
>> either of those RNGs yet.
> Are you sure? This is from 9.0:

Ahh, thanks for double-checking this.  You're right, kfreebsd-i386
kernels already supported the RNG in VIA Eden 32-bit CPUs... since 5.3.
 9.1 merely adds support for the RNG in Via Nano 64-bit CPUs.

Actually, it seems I have kfreebsd-i386 9.0 running on a VIA Eden CPU
right now with hardware RNG - should be handy for testing:

> CPU: VIA Eden Processor  500MHz (498.76-MHz 686-class CPU)
>   Origin = "CentaurHauls"  Id = 0x6d0  Family = 6  Model = d  Stepping = 0
>   Features2=0x4181<SSE3,EST,TM2,xTPR>
>   AMD Features=0x100000<NX>
>   VIA Padlock Features=0xffcc<RNG,AES,AES-CTR,SHA1,SHA256,RSA>

There was no tunable to control use of this RNG until r240950 (which
went into the 9.2 release).  The changelog of when it was MFC'd doesn't
specifically mention that, but the original commit r240135 does:

> Also add the tunables to disable hardware generator
> even if detected.

We could perhaps backport the tunable, then apply the patch for
EN-14:01.random as-is;  thus disabling the RNG by default but providing
a loader tunable to turn it back on.

And there was also this ironic snippet:

> From the Intel whitepapers and articles about Bull Mountain, it seems
> that we do not need to perform post-processing of RDRAND results, [...]
> Intel claims that sanitization is performed in hardware.

I've no reason to think VIA / Centaur Technology (Taiwanese owned) were
participating in the NSA's project BULLRUN, but it's nice that kfreebsd
10 is taking a cautious approach to all hardware RNGs now.

In any case, FreeBSD did an extra step of AES whitening on the output of
VIA's RNG - which was a nice precaution, especially in case of a
hardware defect - though it is still performed on-chip so can't be 100%

Steven Chamberlain

Reply to: