lkml.org 
[lkml]   [2022]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[PATCH 00/10] Encrypted Hibernation
    Date
    We are exploring enabling hibernation in some new scenarios. However,
    our security team has a few requirements, listed below:
    1. The hibernate image must be encrypted with protection derived from
    both the platform (eg TPM) and user authentication data (eg
    password).
    2. Hibernation must not be a vector by which a malicious userspace can
    escalate to the kernel.

    Requirement #1 can be achieved solely with uswsusp, however requirement
    2 necessitates mechanisms in the kernel to guarantee integrity of the
    hibernate image. The kernel needs a way to authenticate that it generated
    the hibernate image being loaded, and that the image has not been tampered
    with. Adding support for in-kernel AEAD encryption with a TPM-sealed key
    allows us to achieve both requirements with a single computation pass.

    Matthew Garrett published a series [1] that aligns closely with this
    goal. His series utilized the fact that PCR23 is a resettable PCR that
    can be blocked from access by usermode. The TPM can create a sealed key
    tied to PCR23 in two ways. First, the TPM can attest to the value of
    PCR23 when the key was created, which the kernel can use on resume to
    verify that the kernel must have created the key (since it is the only
    one capable of modifying PCR23). It can also create a policy that enforces
    PCR23 be set to a specific value as a condition of unsealing the key,
    preventing usermode from unsealing the key by talking directly to the
    TPM.

    This series adopts that primitive as a foundation, tweaking and building
    on it a bit. Where Matthew's series used the TPM-backed key to encrypt a
    hash of the image, this series uses the key directly as a gcm(aes)
    encryption key, which the kernel uses to encrypt and decrypt the
    hibernate image in chunks of 16 pages. This provides both encryption and
    integrity, which turns out to be a noticeable performance improvement over
    separate passes for encryption and hashing.

    The series also introduces the concept of mixing user key material into
    the encryption key. This allows usermode to introduce key material
    based on unspecified external authentication data (in our case derived
    from something like the user password or PIN), without requiring
    usermode to do a separate encryption pass.

    Matthew also documented issues his series had [2] related to generating
    fake images by booting alternate kernels without the PCR23 limiting.
    With access to PCR23 on the same machine, usermode can create fake
    hibernate images that are indistinguishable to the new kernel from
    genuine ones. His post outlines a solution that involves adding more
    PCRs into the creation data and policy, with some gyrations to make this
    work well on a standard PC.

    Our approach would be similar: on our machines PCR 0 indicates whether
    the system is booted in secure/verified mode or developer mode. By
    adding PCR0 to the policy, we can reject hibernate images made in
    developer mode while in verified mode (or vice versa).

    Additionally, mixing in the user authentication data limits both
    data exfiltration attacks (eg a stolen laptop) and forged hibernation
    image attacks to attackers that already know the authentication data (eg
    user's password). This, combined with our relatively sealed userspace
    (dm-verity on the rootfs), and some judicious clearing of the hibernate
    image (such as across an OS update) further reduce the risk of an online
    attack. The remaining attack space of a forgery from someone with
    physical access to the device and knowledge of the authentication data
    is out of scope for us, given that flipping to developer mode or
    reflashing RO firmware trivially achieves the same thing.

    A couple of patches still need to be written on top of this series. The
    generalized functionality to OR in additional PCRs via Kconfig (like PCR
    0 or 5) still needs to be added. We'll also need a patch that disallows
    unencrypted forms of resume from hibernation, to fully close the door
    to malicious userspace. However, I wanted to get this series out first
    and get reactions from upstream before continuing to add to it.

    [1] https://patchwork.kernel.org/project/linux-pm/cover/20210220013255.1083202-1-matthewgarrett@google.com/
    [2] https://mjg59.dreamwidth.org/58077.html


    Evan Green (6):
    security: keys: trusted: Verify creation data
    PM: hibernate: Add kernel-based encryption
    PM: hibernate: Use TPM-backed keys to encrypt image
    PM: hibernate: Mix user key in encrypted hibernate
    PM: hibernate: Verify the digest encryption key
    PM: hibernate: seal the encryption key with a PCR policy

    Matthew Garrett (4):
    tpm: Add support for in-kernel resetting of PCRs
    tpm: Allow PCR 23 to be restricted to kernel-only use
    security: keys: trusted: Parse out individual components of the key
    blob
    security: keys: trusted: Allow storage of PCR values in creation data

    Documentation/power/userland-swsusp.rst | 8 +
    .../security/keys/trusted-encrypted.rst | 4 +
    drivers/char/tpm/Kconfig | 10 +
    drivers/char/tpm/tpm-dev-common.c | 8 +
    drivers/char/tpm/tpm-interface.c | 28 +
    drivers/char/tpm/tpm.h | 23 +
    drivers/char/tpm/tpm1-cmd.c | 69 ++
    drivers/char/tpm/tpm2-cmd.c | 58 +
    drivers/char/tpm/tpm2-space.c | 2 +-
    include/keys/trusted-type.h | 9 +
    include/linux/tpm.h | 12 +
    include/uapi/linux/suspend_ioctls.h | 28 +-
    kernel/power/Kconfig | 15 +
    kernel/power/Makefile | 1 +
    kernel/power/power.h | 1 +
    kernel/power/snapenc.c | 1076 +++++++++++++++++
    kernel/power/snapshot.c | 5 +
    kernel/power/user.c | 44 +-
    kernel/power/user.h | 114 ++
    security/keys/trusted-keys/trusted_tpm1.c | 9 +
    security/keys/trusted-keys/trusted_tpm2.c | 164 ++-
    21 files changed, 1670 insertions(+), 18 deletions(-)
    create mode 100644 kernel/power/snapenc.c
    create mode 100644 kernel/power/user.h

    --
    2.31.0

    \
     
     \ /
      Last update: 2022-05-05 01:49    [W:2.931 / U:0.644 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site