Re: [PATCH 0/6] Intel Secure Guard Extensions

From: Andy Lutomirski <luto@amacapital.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg KH <gregkh@linuxfoundation.org>,
	Mathias Krause <minipli@googlemail.com>,
	Borislav Petkov <bp@suse.de>,
	"open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Wan Zongshun <Vincent.Wan@amd.com>,
	Kristen Carlson Accardi <kristen@linux.intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions
Date: Tue, 26 Apr 2016 15:33:55 -0700	[thread overview]
Message-ID: <CALCETrX_-SCToegw37qrMhDXH5W+d2bR367Tc5D6x9554OoKeQ@mail.gmail.com> (raw)
In-Reply-To: <20160426201154.GC11111@amd>

On Apr 26, 2016 1:11 PM, "Pavel Machek" <pavel@ucw.cz> wrote:
>
> Hi!
>
> > >> >> The firmware uses PRMRR registers to reserve an area of physical memory
> > >> >> called Enclave Page Cache (EPC). There is a hardware unit in the
> > >> >> processor called Memory Encryption Engine. The MEE encrypts and decrypts
> > >> >> the EPC pages as they enter and leave the processor package.
> > >> >
> > >> > What are non-evil use cases for this?
> > >>
> > >> Storing your ssh private key encrypted such that even someone who
> > >> completely compromises your system can't get the actual private key
> > >
> > > Well, if someone gets root on my system, he can get my ssh private
> > > key.... right?
> > >
> > > So, you can use this to prevent "cold boot" attacks? (You know,
> > > stealing machine, liquid nitrogen, moving DIMMs to different machine
> > > to read them?) Ok. That's non-evil.
> >
> > Preventing cold boot attacks is really just icing on the cake.  The
> > real point of this is to allow you to run an "enclave".  An SGX
> > enclave has unencrypted code but gets access to a key that only it can
> > access.  It could use that key to unwrap your ssh private key and sign
> > with it without ever revealing the unwrapped key.  No one, not even
> > root, can read enclave memory once the enclave is initialized and gets
> > access to its personalized key.  The point of the memory encryption
> > engine to to prevent even cold boot attacks from being used to read
> > enclave memory.
>
> Ok, so the attacker can still access the "other" machine, but ok, key
> is protected.
>
> But... that will mean that my ssh will need to be SGX-aware, and that
> I will not be able to switch to AMD machine in future. ... or to other
> Intel machine for that matter, right?

That's the whole point.  You could keep an unwrapped copy of the key
offline so you could provision another machine if needed.

>
> What new syscalls would be needed for ssh to get all this support?

This patchset or similar, plus some user code and an enclave to use.

Sadly, on current CPUs, you also need Intel to bless the enclave.  It
looks like new CPUs might relax that requirement.

>
> > > Is there reason not to enable this for whole RAM if the hw can do it?
> >
> > The HW can't, at least not in the current implementation.  Also, the
> > metadata has considerable overhead (no clue whether there's a
> > performance hit, but there's certainly a memory usage hit).
>
> :-(.
>
> > >> out.  Using this in conjunction with an RPMB device to make it Rather
> > >> Difficult (tm) for third parties to decrypt your disk even if you
> > >> password has low entropy.  There are plenty more.
> > >
> > > I'm not sure what RPMB is, but I don't think you can make it too hard
> > > to decrypt my disk if my password has low entropy. ... And I don't see
> > > how encrypting RAM helps there.
> >
> > Replay Protected Memory Block.  It's a device that allows someone to
> > write to it and confirm that the write happened and the old contents
> > is no longer available.  You could use it to implement an enclave that
> > checks a password for your disk but only allows you to try a certain
> > number of times.
>
> Ookay... I guess I can get a fake Replay Protected Memory block, which
> will confirm that write happened and not do anything from China, but
> ok, if you put that memory on the CPU, you raise the bar to a "rather
> difficult" (tm) level. Nice.

It's not so easy for the RPMB to leak things.  It would be much easier
for it to simply not provide replay protection (i.e. more or less what
the FBI asked from Apple: keep allowing guesses even though that
shouldn't work).

>
> But that also means that when my CPU dies, I'll no longer be able to
> access the encrypted data.

You could implement your own escrow policy and keep a copy in the safe.

>
> And, again, it means that quite complex new kernel-user interface will
> be needed, right?

It's actually fairly straightforward, and the kernel part doesn't care
what you use it for (the kernel part is the same for disk encryption
and ssh, for example, except that disk encryption would care about
replay protection, whereas ssh wouldn't).

--Andy