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

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



Forwarding to the other lists from original thread...

-------- Original Message --------
Subject: Re: Fwd: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
Date: Sun, 15 Dec 2013 20:53:19 +0100
From: Yves-Alexis Perez <corsac@debian.org>
To: Robert Millan <rmh@debian.org>
CC: team@security.debian.org

On Sat, Dec 14, 2013 at 12:27:27PM +0100, Robert Millan wrote:
> 
> Used the wrong address for Security Team. Sorry!
> 
> -------- Original Message --------
> Subject: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
> Date: Sat, 14 Dec 2013 01:44:16 +0100
> From: Robert Millan <rmh@debian.org>
> To: debian-security@lists.debian.org
> CC: debian-kernel@lists.debian.org,  "debian-bsd@lists.debian.org" <debian-bsd@lists.debian.org>
> 
> 
> According this publication [0], The New York Times, Pro Publica, and The Guardian,
> reported in September that the NSA and its British counterpart are working with
> chipmakers to insert backdoors, or cryptographic weaknesses, in their products.
> 
> [0] http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/
> 
> Software trusting chip-based crypto support, and in particular software which
> uses specialized chips to obtain entropy might be compromising the quality of
> the entropy pool as made available to /dev/random.
> 
> This has been recently discussed at security conference in EuroBSDcon 2013. The
> minutes read:
> 
> "we are going to backtrack and remove RDRAND and Padlock backends and feed
> them into Yarrow instead of delivering their output directly to /dev/random.
> It will still be possible to access hardware random number generators, that
> is, RDRAND, Padlock etc., directly by inline assembly or by using OpenSSL
> from userland, if required, but we cannot trust them any more"
> 
> (from http://www.freebsd.org/news/status/report-2013-09-devsummit.html#Security)
> 
> In consequence the FreeBSD project has deemed it necessary to unlink entropy
> providers in Intel RDRAND and Via Padlock technologies from the main
> /dev/random source (http://svnweb.freebsd.org/base?view=revision&revision=256377).
> 
> Advice from Security Team would be appreciated in order to determine which
> action needs to be taken in Debian.

Well, considering kFreeBSD is not more than a technology preview at that
point and the fact it's never been considered really safe to really on
one single source of entropy (be it hardware based or not, rumored
backdoored or not), I'm not sure we need to rush for a kFreeBSD DSA.

That beeing said, I'm all for pushing updates backporting the fixed
behavior of mixing everything, but I guess that can be part of a more
general release.

Regards,
-- 
Yves-Alexis


Reply to: