Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

The following reply was made to PR port-xen/40739; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: Christoph Badura <bad%bsd.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2
        XEN3PAE_DOMU
Date: Tue, 3 Mar 2009 11:02:01 +0100

 On Mon, Mar 02, 2009 at 11:32:52PM +0100, Christoph Badura wrote:
 > [I have changed the order of the quoted text slightly.]
 > 
 > On Thu, Feb 26, 2009 at 08:20:06PM +0100, Manuel Bouyer wrote:
 > > On Thu, Feb 26, 2009 at 12:45:23PM +0100, Christoph Badura wrote:
 > > >  I'm not sure I
 > > > buy the assertion that other domUs could interfere with the entropy 
 > > > collection.
 > > I'm not a crypto expert, but another domU can cause predictible delays in
 > > disk I/O and I suspect this is bad for entropy.
 > > > What is the actual way to interfere with entropy collection, BTW?
 > > AFAIK entropy collection on peripherals is based on delays. Anything that
 > > can cause or add predictible delays to I/O can interfere.
 > 
 > There are two flaws in your argument: 1) entropy collection isn't based on
 > delay and 2) you haven't described an attack.
 > 
 > Entropy collection on peripherals is *not* based on delay.  It is based on
 > jitter in the timing of interrupt delivery relative to a clock source in
 > the system. So, even if the I/Os would be delayed there would still be a
 > bit of jitter in the interrupt delivery and that jitter is the entropy that
 > is extracted.
 
 OK, so you call jitter what I call delay. Whatever ...
 
 > 
 > rnd(4) filters samples for non-linear jitter and credits them with 1 bit of
 > entropy if they are judged random enough.
 > 
 > Assuming that someone is indeed able to "cause predictible delays in disk 
 > I/O"
 > what effects would that have?
 > 
 > The attacker can reduce the amount of entropy that is collected in a given
 > time frame.  But there's still randomness to be found in anyway.  Obviously
 > this situation is preferable to not collecting any entropy at all.
 > This isn't a reason to prevent the collection of entropy or to disable it
 > by default.  If users run their domUs in such a hostile environment they
 > can disable entropy collection by themselves.
 > 
 > The commonly discussed attack is that an attacker may be able to figure
 > out the random data was handed to a security sensitive processes, say to
 > be used as nonce or key material.  However, for this attack you need to
 > know the exact state of the random pool.  And you can't know that by just
 > manipulating the delay of the I/O requests.  You'd need access to the
 > actual memory that stores the data.
 > 
 > Neither scenario is a reason not to try to collect entropy from as many
 > sources as possible -- quite the contrary actually.
 
 OK, so why is entropy collection disabled by default for all network
 interfaces ? Your demonstration would apply to network interfaces as well.
 
 > 
 > If you fear a flaw in or a breakdown of the algorithms inside rnd(4) that
 > is an orthogonal issue.
 > 
 > > > And if they did, wouldn't that then be true for xennet, too?
 > > it is, not only for xennet but for any interface on a shared network.
 > > that's why entropy collection on network interfaces is disabled by default
 > 
 > But being connected to a switch is *not* being on a shared network, because
 > it hides traffic from other machines in the same logical (sub) network.
 
 not really, as another host on the same switch can affect jitter for
 a given host (even if they are on different vlans).
 
 > 
 > > > Entropy collection from xbd isn't disabled in Xen2 domUs.
 > > that's a mistake.
 > 
 > I wonder on what authority you claim that?  To me it looks very much like
 > you are pulling vague arguments out of thin air and demand that a crypto
 > researcher refutes them.  If you want to continue this argument, why don't
 > you find and expert that backs up your claims?
 
 Why don't you find one that back yours ? 
 In this regard domU I/Os works in the exact same way as network I/O though
 a hub or a switch: requests from different domUs are multiplexed to the
 same ressource. Thinks would be different if the I/O 
 
 > 
 > I wonder on what authority you claim that?
 
 I don't have authority; but until I find someone which can show that
 an attack is not possible though xen block devices, I'll be conservative.
 
 -- 
 Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
      NetBSD: 26 ans d'experience feront toujours la difference
 --