Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets

Arnold Reinhold <agr@me.com> Tue, 18 March 2014 00:42 UTC

Return-Path: <agr@me.com>
X-Original-To: dsfjdssdfsd@ietfa.amsl.com
Delivered-To: dsfjdssdfsd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597D31A0308 for <dsfjdssdfsd@ietfa.amsl.com>; Mon, 17 Mar 2014 17:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU2toqDCp7ZA for <dsfjdssdfsd@ietfa.amsl.com>; Mon, 17 Mar 2014 17:42:23 -0700 (PDT)
Received: from nk11p00mm-asmtp003.mac.com (nk11p00mm-asmtp003.mac.com [17.158.161.2]) by ietfa.amsl.com (Postfix) with ESMTP id 68D071A0303 for <dsfjdssdfsd@ietf.org>; Mon, 17 Mar 2014 17:42:22 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="windows-1252"
Received: from [192.168.1.134] (c-66-31-43-48.hsd1.ma.comcast.net [66.31.43.48]) by nk11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N2L00EVIWMCJL70@nk11p00mm-asmtp003.mac.com> for dsfjdssdfsd@ietf.org; Tue, 18 Mar 2014 00:42:14 +0000 (GMT)
From: Arnold Reinhold <agr@me.com>
In-reply-to: <20140316171716.GD31988@thunk.org>
Date: Mon, 17 Mar 2014 20:43:36 -0400
Content-transfer-encoding: quoted-printable
Message-id: <D1CAFBA9-92AB-4CE6-871E-740A428DA859@me.com>
References: <531F6068.4080907@akr.io> <20140311195443.GD2190@thunk.org> <F3B65184-1544-48FA-8C20-52FEAC208D8A@me.com> <56491888.20140315165037@gmail.com> <DF42CACF-3AC7-4FA9-934C-18D4A0504FB9@me.com> <20140316171716.GD31988@thunk.org>
To: tytso@mit.edu
X-Mailer: Apple Mail (2.1874)
x-icloud-spam-score: 34444444 f=me.com; e=me.com; is=no; ir=yes; pp=ham; spf=n/a; dkim=n/a; dmarc=n/a; wl=n/a; pwl=n/a; clxs=n/a; clxl=n/a
X-MANTSH: 1TEIXREEbG1oaGkdHB0lGUkdDRl5PWBoaHxEKTEMXGx0EGx8SBBscHwQdGxAbHho fGhEKWE0XSxEKbX4XGhEKTFkXGxobGxEKWUkXEQpZXhdoY3kRCkNOF0sbGxpiTk0caBsdcBl4c wcYYxoaHhhvEhEKWFwXGQQaBB0HTUsdEkhJHEwFGx0EGx8SBBscHwQdGxAbHhofGxEKXlkXYXJ +WWgRCkxGF2xraxEKQ1oXHBwEGRsEHhkEHhIRCkRYFxkRCkRJFxgRCkJGF2x9TER+fWUTaV4TE QpCRRd6f314WmxMXkNiQBEKQk4XbHBgeUAdYlJpGmIRCkJMF21oe2BOY0UFBWFoEQpCbBdnfnB FRFl6SEF9HBEKQkAXZGZdZm5LfkscWV4RCnBoF2cTQmlgfWV6ZEtuEQpwaBdlS29rYExZen8BE xEKcGgXYG56eX0faxxFGkMRCnBoF2JtHRN+YERDWmUTEQpwaBdjElheQWVTZVwBHhEKcGwXbn9 kQ21zfkQebhMR
Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/9WKgZycgeWvD-z3XBU_bFqt94hA
Cc: "\"Krisztián Pintér @thunk.org\"" <pinterkr@gmail.com>, dsfjdssdfsd@ietf.org
Subject: Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets
X-BeenThere: dsfjdssdfsd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <dsfjdssdfsd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dsfjdssdfsd/>
List-Post: <mailto:dsfjdssdfsd@ietf.org>
List-Help: <mailto:dsfjdssdfsd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Mar 2014 00:42:25 -0000

On Mar 16, 2014, at 1:17 PM, tytso@mit.edu wrote:

> On Sun, Mar 16, 2014 at 11:18:29AM -0400, Arnold Reinhold wrote:
>> 
>> And note that not all the issues I raised are software
>> related. Tempest, for example, is a very tricky business. The NSA
>> specs for Tempest protection are not publicly available, but I have
>> been told they require tight physical configuration control, as even
>> a single wire change can destroy Tempest protection.  Perhaps the
>> best that can be achieved is to keep any attacker a safe distance
>> from critical systems. A determined attacker might be willing to
>> absorb the effort and risk to covertly penetrate physical security
>> barriers if doing so will lead to a permanent compromise of a
>> one-time-seeded PRNG, less so if the benefits will last only briefly
>> as the PRNG reseeds after they leave.
> 
> One of the things which is not obvious is whether or not each
> contributor has the same threat model in mind.  (In fact, it seems
> pretty obvious to me that we don't all share the same threat model,
> but I'm trying to be polite.  :-)
> 
> The sort of things that you might need to worry about if you are
> trying to protect against pervasive monitoring are very different if
> you are worried about a targetted attack.  If someone is willing to
> bring in a listening truck and park it outside your house, or coverly
> penetrate physical security, there is a whole host of things that you
> would need to protect against before you are fully protected against
> that level of attack.
> 
> In particular, who cares about how carefully constructed your RNG
> might be if the attacker can replace it (along with perhaps your
> entire networking stack, and the monitoring tools that might allow you
> to notice that something strange has happened to your system)?  Or
> just simply drop in some malware which leaks the session key after
> your perfect RNG that meets with all of the academics' worries about
> state compromise recovery….

I agree completely that there are multiple threat models in play regarding RNG and that this is a cause for much confusion. As I see it there are two broad categories:

1. The corporate threat model, which focuses on facilitating e-commerce and financial transections, complying with privacy regulations, (HIPPA, SOX, EU Data Directive, etc.), avoiding potential legal liability and protecting trade secrets.

2. The personal privacy threat model, which fears the mass surveillance society, doesn’t trust corporate vendors and certifying bodies, and considers state actors principal threats. I’d put Bitcoin and the like here.

Intel’s RDrand instruction is a good example of the difference. It is deeply distrusted by group 2, but would appear to meet the needs of  group 1 (except maybe for trade secret protection at non-US companies).

Nonetheless, I would like to see future RNG standards address both groups' concerns as far as reasonably possible. And I would not be dismissive about ”exotic” attacks such as Tempest. What was once the purview of state actors like NSA, e.g. massively parallel machines for brute forcing passwords and keys, is now widely in use by the private and criminal sectors.  

The time interval between RFCs 1750 and 4086 is over ten years and another ten are likely to have elapsed before a successor is adopted. A lot can happen in ten years, so it seems to me the goal should be to recommend the best available technology and to at least consider as many threats and use cases as can be reasonably foreseen, making technical compromises only when clearly needed after due consideration of alternatives.

Arnold Reinhold