Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp530303imm; Fri, 3 Aug 2018 07:25:14 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd/eQ4C14vuHnDaqVPzf79JY4bxdll405i7ZhP4ZuKekxM7L+4Un67NdSfXBwITABIvKMLb X-Received: by 2002:a62:f208:: with SMTP id m8-v6mr4728954pfh.171.1533306314833; Fri, 03 Aug 2018 07:25:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533306314; cv=none; d=google.com; s=arc-20160816; b=c5oMh/Tp6yQS6ZhGD0P/eX5Rt0S7zdycFSII6MSNfHjGTo7mylH/8y+8YGJGK4IJNN uLIonbeIDJRV+2YYuCPC+EeLbj9OJzWu3REMjC29SHRsjsGm+mfpMfGveT5fXBZjvBhK PurQDSIHZgVlWolgEuaOufKQGY1ObrKSPcM7N3iV3XnN4jIbpz3y3D3hHXN09nc2y8RS UoGFe4Z6ZdrkF2J/enK/u3hvv0aO8284lJEznRcXKu4aOgECZv5IIK0K+wQy+H4HRy6n lBclL3SJa7Fh4io9J0Q469wmGqIS/8oPDjXPbOcaNXTdM3LlrisVik2RmO8a8tZ0i5Pn 0wpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:arc-authentication-results; bh=lI/qMpsBLMabIQq1ezBz0onbMOP3gTBIK1zIhukM1bM=; b=d7oWlPnz7C5vXupigrU/AMGkyN73W5a4e+nMMCATMZW1094xo6nIpmofIn+Ma6XRdI dNEaCP/qZ0xPiHJwMrghX1VGZn77TlwAfJ3xr6fKctYBa6oXadw7laXTf2ELi2O3bcDw tTz3jpbEctDUZiWxHktfvEPTS+ZTVg6kfx/RMfg64Hy8HvO3V2zlkCDwWFgR9mh37U61 dgGtB7cS+efdu87LwmM/gWWqVT+UMwTCRwOIxY6Fijk61YsZVR9bR2p1OkSyGXx4A/iq fBNqp1w6u2SgIPX/DxkDsAZk4hD9RROB71+a537h1O/BYzWyr2Y81guM4xa164D2asuq ZYKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=nbp86YCD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k38-v6si4931458pgi.147.2018.08.03.07.25.00; Fri, 03 Aug 2018 07:25:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=nbp86YCD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732397AbeHCQUf (ORCPT + 99 others); Fri, 3 Aug 2018 12:20:35 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:49034 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729985AbeHCQUf (ORCPT ); Fri, 3 Aug 2018 12:20:35 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 4CACE8EE13D; Fri, 3 Aug 2018 07:24:00 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNyBzWWvPIIn; Fri, 3 Aug 2018 07:24:00 -0700 (PDT) Received: from [153.66.254.194] (unknown [50.35.68.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 6455B8EE0C9; Fri, 3 Aug 2018 07:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1533306240; bh=Qo6QBebh2dcnFsD0eKOmARpH88mH1NA0q5hMwfHP9r4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=nbp86YCD1LNBUKCtL8zEsqWUit9FA/9fMLZzRh3R6j7iAfWd8KqUHOtsdiMc/xsnS O4G72hAJw/usU84ur41wXXNQwAp4YKuaUGqErpU0sTRgLXaEHi2RpLjVwMwri5/Cdp Fwq1Py+N8QZHGR/5FV2HZjMT6LBIKdxffW4inqfA= Message-ID: <1533306238.4140.1.camel@HansenPartnership.com> Subject: Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM. From: James Bottomley To: Mimi Zohar , David Howells , Udit Agarwal Cc: zohar@linux.vnet.ibm.com, jmorris@namei.org, serge@hallyn.com, denkenz@gmail.com, linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, sahil.malhotra@nxp.com, ruchika.gupta@nxp.com, horia.geanta@nxp.com, aymen.sghaier@nxp.com Date: Fri, 03 Aug 2018 07:23:58 -0700 In-Reply-To: <1533297482.4337.373.camel@linux.ibm.com> References: <20180723111432.26830-1-udit.agarwal@nxp.com> <8060.1533226481@warthog.procyon.org.uk> <1533297482.4337.373.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-08-03 at 07:58 -0400, Mimi Zohar wrote: > On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote: > > Udit Agarwal wrote: > > > > > +========== > > > +Secure Key > > > +========== > > > + > > > +Secure key is the new type added to kernel key ring service. > > > +Secure key is a symmetric type key of minimum length 32 bytes > > > +and with maximum possible length to be 128 bytes. It is produced > > > +in kernel using the CAAM crypto engine. Userspace can only see > > > +the blob for the corresponding key. All the blobs are displayed > > > +or loaded in hex ascii. > > > > To echo Mimi, this sounds suspiciously like it should have a > > generic interface, not one that's specifically tied to one piece of > > hardware - particularly if it's named with generic "secure". > > > > Can you convert this into a "symmetric" type and make the backend > > pluggable? > > TPM 1.2 didn't support symmetric keys.  For this reason, the TPM > "unseals" the random number, used as a symmetric key, and returns the > "unsealed" data to the kernel. > > Does anyone know if CAAM or TPM 2.0 have support for symmetric keys? It depends what you mean by "support". The answer is technically yes, it's the TPM2_EncryptDecrypt primitive. However, the practical answer is that symmetric keys are mostly used for bulk operations and the TPM and its bus are way too slow to support that, so the only real, practical use case is to have the TPM govern the release conditions for symmetric keys which are later used by a fast bulk encryptor/decryptor based in software. >  If they have symmetric key support, there would be no need for the > symmetric key ever to leave the device in the clear.  The device > would unseal/decrypt data, such as an encrypted key. > > The "symmetric" key type would be a generic interface for different > devices. It's possible, but it would only work for a non-bulk use case; do we have one of those? James