Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp197595imu; Tue, 8 Jan 2019 17:46:33 -0800 (PST) X-Google-Smtp-Source: ALg8bN5SjkiXwmMrbKShucwgAB3qI5pnTJH6YnRl2d9LT2ILtz4a2BjpNURnWBreOgUfD4d+3BGt X-Received: by 2002:a63:1e17:: with SMTP id e23mr1435464pge.130.1546998393610; Tue, 08 Jan 2019 17:46:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546998393; cv=none; d=google.com; s=arc-20160816; b=wOfkWUr1kzWOwUs73buQ1mHDGSaTMJTqPNVOx2Sm4yIuHE9u/+7EvOYCLjm5VzbWai OwokvyU4fh1JMak9NqMboO5/sb6Tagr8mym0F7afMgTJLjuoiKpwO+2Rfyr3ex+iWvRx qR57LumYiORsflYKyf2KCRVbFH8Bltj5jRdWqNPByt1zotBZ0AqQNjar8DZ56JWtV64/ 87+ZkIlQs4RIH5MhBvn968JZ8TMmX4ddx6zPvnWaaeMqt9pTNzb9Avctnqa8+cnxfJj2 YPYeoWI0tj308ekaSNSEQLb4foRB3Xv28DaX5pia0Kd9p7oY6YjbDxPvfsqiMRLt+N6k toiQ== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=56UkJ4YBwibabjo484PHuCpXC40S8zYLo3HhmD/BVGw=; b=u1JC1KUgC8v4cLaxrwV70XOy6mE8aTHBic6LijQtCfPQT0+3ONmAjg4G5vpCUFbVkJ 02pR5hQTjYK1BJZ4kFtGMlLzfdabq83x6WIl9U3SmNuFrniIzFSpSC0t++I9BrB1jIaj b/FYstG2qy6gluLi+/eat0GyoRoBxCNArra7MVh8pqF5h8FVSXbzTHujUHpnlVGj1lgb 2GqQepuby+z0sSXohX75vo6r92g36PxPxEuFOQR2aV13IjmJsNj61mJI3G0umAz0b7Ow Ib8MxJfFFGxFCsUgBZARXFtSYSK4M0PAcMvIggmzL1pKw/Mh2zQD3bASWIF3msov+HGq VqJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=e1qFIB9y; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g32si36858846pgg.400.2019.01.08.17.46.17; Tue, 08 Jan 2019 17:46:33 -0800 (PST) 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=pass header.i=@kernel.org header.s=default header.b=e1qFIB9y; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729433AbfAIBoK (ORCPT + 99 others); Tue, 8 Jan 2019 20:44:10 -0500 Received: from mail.kernel.org ([198.145.29.99]:42590 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729277AbfAIBoK (ORCPT ); Tue, 8 Jan 2019 20:44:10 -0500 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 463DD21872 for ; Wed, 9 Jan 2019 01:44:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546998248; bh=Os7GiwN54DZ3wpzOMLgn+usmROqaPalWDiPuh4BLhqs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=e1qFIB9yCcPEYwy6JnsUcr/14KMNc+tnnMYNcqmflfxWZXBEyIxE6br1uwbt+mi/4 h4qjof7xwG9xkVl/QOMOGYn+Vd5WJiGZ335KRZQvghcGIPTBHqg4Z2HFoGh1hxP7ox IEtdpxEkKxuMpd3dxS0oOZRSwChpwP4JRUTIN3/4= Received: by mail-wm1-f50.google.com with SMTP id y185so9754621wmd.1 for ; Tue, 08 Jan 2019 17:44:08 -0800 (PST) X-Gm-Message-State: AJcUukcAc8qCKuEuIf2ZvW6CfpEIL34AuqTNDQAWNGxeQMaJaAWXsKcj +pGp8fwXODfv3LpZbToxLQF6W67lnoIdmDOfc5kTLw== X-Received: by 2002:a7b:c7c7:: with SMTP id z7mr3768087wmk.74.1546998246556; Tue, 08 Jan 2019 17:44:06 -0800 (PST) MIME-Version: 1.0 References: <20190103143227.9138-1-jlee@suse.com> <4499700.LRS4F2YjjC@tauon.chronox.de> <20190108050358.llsox32hggn2jioe@gondor.apana.org.au> <1565399.7ulKdI1fm5@tauon.chronox.de> <1546994671.6077.10.camel@HansenPartnership.com> In-Reply-To: <1546994671.6077.10.camel@HansenPartnership.com> From: Andy Lutomirski Date: Tue, 8 Jan 2019 17:43:53 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler To: James Bottomley , Jarkko Sakkinen Cc: Stephan Mueller , Herbert Xu , "Lee, Chun-Yi" , "Rafael J . Wysocki" , Pavel Machek , LKML , linux-pm@vger.kernel.org, keyrings@vger.kernel.org, "Rafael J. Wysocki" , Chen Yu , Oliver Neukum , Ryan Chen , David Howells , Giovanni Gherdovich , Randy Dunlap , Jann Horn , Andy Lutomirski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Adding Jarkko because this stuff relates to the TPM.] On Tue, Jan 8, 2019 at 4:44 PM James Bottomley wrote: > > On Tue, 2019-01-08 at 15:54 -0800, Andy Lutomirski wrote: > > > On Jan 7, 2019, at 11:09 PM, Stephan Mueller > > > wrote: > > > > > > Am Dienstag, 8. Januar 2019, 06:03:58 CET schrieb Herbert Xu: > > > > > > Hi Herbert, > > > > > > > Are we going to have multiple implementations for the same KDF? > > > > If not then the crypto API is not a good fit. To consolidate > > > > multiple implementations of the same KDF, simply provide helpers > > > > for them. > > > > > > It is unlikely to have multiple implementations of a KDF. However, > > > KDFs relate to hashes like block chaining modes to raw block > > > ciphers. Thus a KDF can be applied with different hashes. > > > > > > My idea was to add template support to RNGs (because KDFs are > > > effectively a type of RNG since they produce an arbitrary output > > > from a fixed input). The KDFs would be a template wrapping hashes. > > > For example, the CTR-KDF from SP800-108 could be instantiated like > > > kdf-ctr(sha256). > > > > > > > > > > I think that, if the crypto API is going to grow a KDF facility, it > > should be done right. Have a key type or flag or whatever that says > > =E2=80=9Cthis key may *only* be used to derive keys using such-and-such > > algorithm=E2=80=9D, and have a helper to derive a key. That helper sho= uld > > take some useful parameters and mix them in: > > > > - What type of key is being derived? ECDSA signing key? HMAC > > key? AES key? > > > > - Can user code access the derived key? > > > > - What is the key=E2=80=99s purpose? =E2=80=9CEncrypt and authenticate= a hibernation > > image=E2=80=9D would be a purpose. > > > > - Number of bytes. > > > > All of these parameters should be mixed in to the key derivation. > > > > Also, an AE key, even for AES+HMAC, should be just one derived > > key. If you need 512 bits, ask for a 512-bit key, not two 256-bit > > keys. > > Actually, it would be enormously helpful if we could reuse these pieces > for the TPM as well. It has two KDFs: KDFa, which is the CTR-KDF from > SP800-108 and KDFe which is the SP800-56A KDF for elliptic curve one > pass Diffie Hellman, so if we're going to do the former, I'd really > like the latter as well. > > The way the TPM parametrises input to both KDFs is > > (hashAlg, key, label, contextU, contextV, bits) > > Where > > hashAlg =3D the hash algorithm used as the PRF > key =3D the input parameter of variable bit size or > the x co-ordinate of the shared point > label =3D An ASCII string representing the use > contextU =3D public input U > contextV =3D public input V > bits =3D number of output bits > > Is that a good enough parametrisation (not the only way you distinguish > uses is with the label, which is not recoverable)? ContextU and > ContextV are simply concatenated to form the full Context of SP800-108, > but we tend to need two separate inputs (for KDFe they're the public x > co-ordinates of the points of the two inputs to ECDH for instance; in > KDFa they're usually the local and remote nonces). > > The labels for TPM usage are things like "INTEGRITY" for HMAC keys or > "CFB" when generating an aes128-cfb session key. For KDFe, the tpm > seems to like the label "SECRET". Although the TPM specifies fixed > short strings for the label, nothing prevents them being longer like > the purpose you state above (essentially we could mix purpose, use and > key type into the label and the contexts). > That really ought to cover anything the kernel needs. But can you explain what's up with with KDFe? The obvious searches end up with just warnings that the US currently has no government :( Anyway, if we're talking about the TPM, it seems like the entire "trusted key" mechanism in the kernel is missing the point. If I want to encrypt something like a hibernation image on a machine with a TPM, it makes essentially no sense to me that we would get a key with a known raw value that is merely TPM-backed (i.e. the "trusted key") and use that to decrypt the image. The right way to do it is to the use the TPM as it was intended to be used: generate a single-use key that protects the hibernation image and seal *that* directly on the TPM, such that it can only be unsealed with appropriate PCR values. Heck, we could even use one of the fancy NV counters such that we *can't* decrypt the image later on. And using HMAC or any AE construction the normal way is also wrong -- we should *hash* the image and sign the hash directly on the TPM so that the restore code can validate the PCR values that were in place when the hibernation image was created. [0] In other words, I think that a kernel-based encrypted hibernation mechanism should create an image like this: - wrapped key - instructions, if needed, for unwrapping - hash of the entire image except the hash and signature fields - signature of the hash and the remainder is a regular hiberation image that is encrypted against the key. No AE is needed -- just encryption. And there's no trampoline, no weird per-page hashing, etc. Of course, this also means that someone needs to audit the hibernation restore code to make sure that there's no way for a malicious image to gain code execution over the restoring kernel before the verification even runs. Or some much more complicated hash can be used that supports incremental verification. (Also, do we have a sensible story of how the TPM interacts with hibernation at all? Presumably we should at least try to replay the PCR operations that have occurred so that we can massage the PCRs into the same state post-hibernation. Also, do we have any way for the kernel to sign something with the TPM along with an attestation that the signature was requested *by the kernel*? Something like a sub-hierarchy of keys that the kernel explicitly prevents userspace from accessing?) [0] If you take some data, run it through an authenticated encryption algorithm, and sign (key, nonce, tag), I think you're operating outside of the accepted security definitions if you expect this to guarantee that the data wasn't tampered with. I'm reasonably confident that there are quite a few excellent AE algorithms that completely fail if used this like this. In fact, pretty much all of the modern fast ones probably fail. AE is for when the key is *secret*.