lkml.org 
[lkml]   [2019]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler
    From
    Date
    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

    \
     
     \ /
      Last update: 2019-01-11 16:29    [W:6.082 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site