linux-kernel - Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Jan 2019 07:28:58 -0800
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>
Cc:     Stephan Mueller <smueller@...onox.de>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "Lee, Chun-Yi" <joeyli.kernel@...il.com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Pavel Machek <pavel@....cz>,
        LKML <linux-kernel@...r.kernel.org>, linux-pm@...r.kernel.org,
        keyrings@...r.kernel.org,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Chen Yu <yu.c.chen@...el.com>,
        Oliver Neukum <oneukum@...e.com>,
        Ryan Chen <yu.chen.surf@...il.com>,
        David Howells <dhowells@...hat.com>,
        Giovanni Gherdovich <ggherdovich@...e.cz>,
        Randy Dunlap <rdunlap@...radead.org>,
        Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

On Fri, 2019-01-11 at 16:02 +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 08, 2019 at 05:43:53PM -0800, Andy Lutomirski wrote:
> > (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?)
> 
> Kernel can keep it is own key hierarchy in memory as TPM2 chips allow
> to offload data in encrypted form and load it to TPM when it needs to
> use it.
> 
> The in-kernel resource manager that I initiated couple years ago
> provides this type of functionality.

Actually, the resource manager only keeps volatile objects separated
when in use not when offloaded.  The problem here is that the object
needs to be persisted across reboots, so either it gets written to the
NV area, bypassing the resource manager and making it globally visible
or it has to get stored in TPM form in the hibernation image, meaning
anyone with access to the TPM who can read the image can extract and
load it. Further: anyone with access to the TPM can create a bogus
sealed key and encrypt a malicious hibernation image with it.  So there
are two additional problems

   1. Given that the attacker may have access to the binary form of the
      key, can we make sure only the kernel can get it released?
   2. How do we prevent an attacker with access to the TPM from creating a
      bogus sealed key?

This is why I was thinking localities.

James