From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753411Ab3IKBuO (ORCPT <rfc822;w@1wt.eu>);
	Tue, 10 Sep 2013 21:50:14 -0400
Received: from mail-pb0-f50.google.com ([209.85.160.50]:50249 "EHLO
	mail-pb0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751525Ab3IKBuM (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 10 Sep 2013 21:50:12 -0400
Message-ID: <522FCC51.1010604@amacapital.net>
Date: Tue, 10 Sep 2013 18:50:09 -0700
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: "H. Peter Anvin" <hpa@zytor.com>
CC: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>,
        Ashley Lai <ashley@ashleylai.com>, Rajiv Andrade <mail@srajiv.net>,
        Marcel Selhorst <tpmdd@selhorst.net>, Sirrix AG <tpmdd@sirrix.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Jeff Garzik <jgarzik@pobox.com>, "Ted Ts'o" <tytso@mit.edu>,
        Kent Yoder <key@linux.vnet.ibm.com>,
        David Safford <safford@watson.ibm.com>, Mimi Zohar <zohar@us.ibm.com>,
        "Johnston, DJ" <dj.johnston@intel.com>
Subject: Re: TPMs and random numbers
References: <522E3997.9030109@zytor.com>
In-Reply-To: <522E3997.9030109@zytor.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 09/09/2013 02:11 PM, H. Peter Anvin wrote:
> It recently came to my attention that there are no standards whatsoever
> for random number generated by TPMs.  In fact, there *are* TPMs where
> random numbers are generated by an encrypted nonvolatile counter (I do
> not know which ones); this is apparently considered acceptable for the
> uses of random numbers that TPMs produce.
> 
> There are two issues with this from a Linux point of view.  One, we
> harvest supposed entropy from the TPM for /dev/*random use via
> /dev/hwrng and rngd.  This was something I originally proposed because
> on a lot of platforms it is the only available entropy source with any
> significant bandwidth.  However, in light of the above it is
> questionable at best, at least with entropy being credited.

Presumably the "entropy" should be mixed in but not credited to the
available entropy.

> 
> The other issue is that we use tpm_get_random() *directly* in
> security/keys/trusted.c.

I don't know whether this makes sense, but all but one call seem to be
related to TPM transactions -- breaking the TPM's RNG won't have any
effects beyond, say, breaking the TPM's SRK.

The one that looks dangerous is the one just under case Opt_new: it's
using tpm_get_random to create an encryption key *that's used by the
kernel for software crypto*.  That's IMO bogus.

--Andy