Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 3 Oct 2019 21:15:31 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To:     Mimi Zohar <zohar@linux.ibm.com>
Cc:     linux-integrity@vger.kernel.org, stable@vger.kernel.org,
        David Howells <dhowells@redhat.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>,
        "open list:ASYMMETRIC KEYS" <keyrings@vger.kernel.org>,
        "open list:CRYPTO API" <linux-crypto@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes()
Message-ID: <20191003181531.GD19679@linux.intel.com>
References: <20190926171601.30404-1-jarkko.sakkinen@linux.intel.com>
 <1570024819.4999.119.camel@linux.ibm.com>
 <20191003114119.GF8933@linux.intel.com>
 <1570107752.4421.183.camel@linux.ibm.com>
 <20191003180201.GC19679@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20191003180201.GC19679@linux.intel.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Thu, Oct 03, 2019 at 09:02:01PM +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 03, 2019 at 09:02:32AM -0400, Mimi Zohar wrote:
> > That isn't a valid justification for changing the original definition
> > of trusted keys. ?Just as the kernel supports different methods of
> > implementing the same function on different architectures, trusted
> > keys will need to support different methods of generating a random
> > number. ??
> 
> This is completely incorrect deduction. The random number generator
> inside the kernel is there to gather entropy from different sources.
> You would exploit trusted keys to potential weaknesses of a single
> entropy source by doing that.
> 
> Of course in TEE platform, TEE can be one of the entropy sources but
> there is no reason to weaken the security by using it as the only
> sources.

I.e. where you go wrong is that you are inter mixing requirements
for the payload and for sealing. They are disjoint assets. The rules
for the payload should not be dependent on how you seal your trusted
key.

/Jarkko