linux-kernel - Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

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]

Message-ID: <20180806103958.GI27062@linux-l9pv.suse>
Date:   Mon, 6 Aug 2018 18:39:58 +0800
From:   joeyli <jlee@...e.com>
To:     Yu Chen <yu.c.chen@...el.com>
Cc:     Pavel Machek <pavel@....cz>, Ryan Chen <yu.chen.surf@...il.com>,
        oneukum@...e.com, "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        ebiggers@...gle.com, Theodore Ts'o <tytso@....edu>,
        smueller@...onox.de, denkenz@...il.com,
        Linux PM list <linux-pm@...r.kernel.org>,
        linux-crypto@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kookoo.gu@...el.com, Zhang Rui <rui.zhang@...el.com>
Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation
 encryption

On Mon, Aug 06, 2018 at 04:45:34PM +0800, Yu Chen wrote:
> Hi Pavel,
> On Sun, Aug 05, 2018 at 12:02:00PM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > > User space doesn't need to involve. The EFI root key is generated by
> > > > EFI boot stub and be transfer to kernel. It's stored in EFI boot service
> > > > variable that it can only be accessed by trusted EFI binary when
> > > > secure boot is enabled.
> > > >
> > > Okay, this apply to the 'suspend' phase, right?
> > > I'm still a little confused about the 'resume' phase.
> > > Taking encryption as example(not signature),
> > > the purpose of doing hibernation encryption is to prevent other users
> > > from stealing ram content. Say, user A uses a  passphrase to generate the
> > 
> > No, I don't think that's purpose here.
> > 
> > Purpose here is to prevent user from reading/modifying kernel memory
> > content on machine he owns.
> >
> Say, A puts his laptop into hibernation and walks away,
> and B walks by, and opens A's laptop and wakes up the system and he
> can do what he wants. Although EFI key/TPM trusted key is enabled,
> currently there's no certification during resume, which sounds
> unsafe to me. Afterall, the original requirement is to probe
> user for password during resume, which sounds more natural.

OK, I saw your case. This is a physical accessing.

I have a question: The suspend to memory also has the same behavior
and more people are using suspend. Should we think a common solution
to cover S3 and S4? 

> > Strange as it may sound, that is what "secure" boot requires (and what
> > Disney wants).
> > 
> Ok, I understand this requirement, and I'm also concerning how to
> distinguish different users from seeing data of each other.
> 
> Joey,
> I'm thinking of a possible direction which could take advantage
> of the password.  It leverages either EFI key or TPM
> trusted key to get it done. Does it make sense?
> 
> 1. The user space generates a symetric key key_user using
>    the password, and passes the key_user to the kernel as the master
>    key.
> 2. The kernel uses the EFI key or TPM trusted key to encrypt
>    the key_user thus gets a encrypt_key.
> 3. Uses the encrypt_key to do snapshot encryption
> 4. During resume, the same encrypt_key is generated following
>    the same steps(I assume the same EFI key or TPM key could be fetched
>    during resumed, right?) and do the snapshot decryption.
>

Yes, we can use TPM key to protect the user key. But I suggest that we
should give user a function to disable the user key because not everyone
want to key-in a password for hibernate/resume and also snapshot image
encryption.

Two policies:
- When user key-in user key, the snapshot image must be encryption.
- Without key-in user key, I still want the snapshot image can be encryption.

No matter that the user key be key-in or not, the snapshot image must be
encrypted by a kernel key. So I suggest that we treat the user key as a salt
for snapshot image encryption and authentication. If the user key
be disabled, then kernel just generates a random number as a salt.

Actually, the kernel must compares the user key before snapshot decryption.
If the user key doesn't match but user space still triggers furture resume
process. Then kernel direct drops the snapshot image. 
 
> And this is what fscrypt is doing:
> Documentation/filesystems/fscrypt.rst
>
The use case is different. We have two key for two purposes. And the two
functions can be separated.

Thanks
Joey Lee