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

[Christoph Badura <bad%bsd.de@localhost>]

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

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

 [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.
 
 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.
 
 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.
 
 > > 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?
 
 I wonder on what authority you claim that?  Your arguments seem very vague
 to me.  Please find and expert to back up your claims.
 
 If you want to discuss this further, I suggest we take it to tech-security.
 In the mean-time I don't see why we should cripple rnd(4) in domUs by default.
 Users who are extra paranoid can disable the sources with rndctl(8).
 
 --chris
 
 P.S. yes, I looked at quite a bit of background literature on this and
 read the rnd(4) sources.